本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

最佳化查詢效能

Amazon QLDB 旨在滿足高效能線上交易處理 (OLTP) 工作負載的需求。這意QLDB味著即使它支持SQL類似查詢功能，也針對一組特定的查詢模式進行了優化。設計應用程式及其資料模型以使用這些查詢模式至關重要。否則，隨著資料表的成長，您將會遇到重大的效能問題，包括查詢延遲、交易逾時和並行衝突。

本節說明中的查詢條件約束，QLDB並提供指引，以撰寫這些條件約束的最佳查詢。

交易逾時限制

在中QLDB，每個 PartiQL 陳述式 (包括每個SELECT查詢) 都會在交易中處理，且受到交易逾時限制的限制。在認可之前，交易最多可以執行 30 秒。在此限制之後，會QLDB拒絕在交易上完成的任何工作，並捨棄執行交易的工作階段。此限制可透過啟動交易而不提交或取消工作階段來保護服務的用戶端不會洩漏工作階段。

并发冲突

QLDB通過使用樂觀並發控制實現並發控制（）OCC。次優查詢也可能導致更多衝突。OCC如需 OCC 的資訊，請參閱「Amazon QLDB 并发模型」。

最佳化查詢模式

最佳做法是，您應該執行含有述WHERE詞子句的陳述式，以篩選索引欄位或文件 ID。QLDB索引欄位上需要相等運算子 (=或IN)，才能有效率地查詢文件。

以下是使用者檢視中最佳化查詢模式的範例。

--Indexed field (VIN) lookup using the = operator
SELECT * FROM VehicleRegistration
WHERE VIN = '1N4AL11D75C109151'

--Indexed field (VIN) AND non-indexed field (City) lookup
SELECT * FROM VehicleRegistration
WHERE VIN = '1N4AL11D75C109151' AND City = 'Seattle'

--Indexed field (VIN) lookup using the IN operator
SELECT * FROM VehicleRegistration
WHERE VIN IN ('1N4AL11D75C109151', 'KM8SRDHF6EU074761')

--Document ID (r_id) lookup using the BY clause
SELECT * FROM VehicleRegistration BY r_id
WHERE r_id = '3Qv67yjXEwB9SjmvkuG6Cp'

任何不遵循這些模式的查詢都會叫用完整資料表掃描。對於大型資料表或傳回大型結果集的查詢，資料表掃描可能會造成交易逾時。它們還可能導致與競爭交易的OCC衝突。

高基數索引

我們建議您對包含高基數值的欄位進行索引。例如，資VehicleRegistration料表中的VIN和LicensePlateNumber欄位都是唯一的索引欄位。

避免索引低基數欄位，例如狀態碼、地址州或省和郵遞區號。如果您為這類欄位建立索引，您的查詢可能會產生較大的結果集，這些結果集較有可能導致交易逾時或造成意外OCC衝突。

已提交檢視查詢

您在已提交檢視中執行的查詢遵循與使用者檢視查詢相同的最佳化準則。您在資料表上建立的索引也會用於已提交檢視中的查詢。

歷史函數查詢

歷史記錄函數查詢不會使用您在表上創建的索引。QLDB歷史記錄僅依文件 ID 編製索引，而且您目前無法建立其他歷程記錄索引。

最佳做法是使用日期範圍 (開始時間和結束時間) 和文件 ID (metadata.id) 來限定歷史記錄查詢。包含開始時間和結束時間的歷史查詢可獲得日期範圍限定的好處。

內部聯結查詢

對於內部聯結查詢，請使用聯結準則，其中至少包含聯結右側資料表的索引欄位。如果沒有聯結索引，聯結查詢會叫用多個資料表掃描 — 對於聯結左側資料表中的每個文件，查詢會完全掃描右側資料表。最佳做法是加入每個您要加入的資料表索引的欄位，以及為至少一個資料表指定WHERE相等述詞。

例如，下列查詢會聯結各自VIN欄位上的VehicleRegistration和Vehicle資料表，這兩個欄位都會建立索引。這個查詢也有一個相等謂詞。VehicleRegistration.VIN

SELECT * FROM VehicleRegistration AS r INNER JOIN Vehicle AS v
ON r.VIN = v.VIN
WHERE r.VIN IN ('1N4AL11D75C109151', 'KM8SRDHF6EU074761')

為聯結準則和聯結查詢中的相等述詞選擇高基數索引。

要避免的查詢模式

以下是一些次優陳述式的範例，這些陳述式對於中較大的資料表而言不能很好地縮放。QLDB我們強烈建議您不要依賴這些類型的查詢，因為您的查詢最終會導致交易逾時。由於表格包含大小不同的文件，因此很難定義非索引查詢的精確限制。

--No predicate clause
SELECT * FROM Vehicle

--COUNT() is not an optimized function
SELECT COUNT(*) FROM Vehicle

--Low-cardinality predicate
SELECT * FROM Vehicle WHERE Color = 'Silver'

--Inequality (>) does not qualify for indexed lookup
SELECT * FROM Vehicle WHERE "Year" > 2019

--Inequality (LIKE)
SELECT * FROM Vehicle WHERE VIN LIKE '1N4AL%'

--Inequality (BETWEEN)
SELECT SUM(PendingPenaltyTicketAmount) FROM VehicleRegistration
WHERE ValidToDate BETWEEN `2020-01-01T` AND `2020-07-01T`

--No predicate clause
DELETE FROM Vehicle

--No document id, and no date range for the history() function
SELECT * FROM history(Vehicle)

一般而言，我們不建議在下列情況下針對生產使用案例執行下列類型的查詢模式QLDB：

相反地，我們建議您將資料串流至針對分析使用案例進行最佳化的專用資料庫服務。例如，您可以將QLDB資料串流至 Amazon OpenSearch 服務，以針對文件提供全文搜尋功能。如需示範此使用案例的範例應用程式，請參閱 GitHub 儲存庫 aws-Sam amazon-qldb-streaming-amazon ples/-。opensearch-service-sample-python如需有關QLDB串流的資訊，請參閱從 Amazon 串流日誌資料 QLDB。

監控效能

QLDB驅動程式會在陳述式的結果物件中提供耗用的 I/O 使用情況和計時資訊。您可以使用這些測量結果來識別效率低下的 PartiQL 陳述式。要了解更多信息，請繼續獲取 PartiQL 語句統計信息。

您也可以使用 Amazon CloudWatch 追蹤分類帳的資料操作效能。監督CommandLatency指定的LedgerName和的測量結果CommandType。如需詳細資訊，請參閱 使用 Amazon 進行監控 CloudWatch。若要瞭解如何QLDB使用指令來管理資料作業，請參閱驅動程式的工作階段管理。