Azure Cosmos DB 中的索引編製原則

發行項
11/19/2024

適用於：NoSQL

在 Azure Cosmos DB 中，每個容器都有索引編製原則，以指示容器項目應該如何編制索引。新建立的容器所套用之每個項目的每個屬性之預設索引編製原則，會對任何字串或數字強制執行範圍索引。這可讓查詢的效能良好，而無須事先考慮索引編製和索引管理。

在某些情況下，您可能想要覆寫此自動行為，使其更符合您的需求。您可設定索引編製模式來自訂容器的索引編製原則，並包含或排除屬性路徑。

注意

本文所述的索引編製原則更新方法僅適用於 Azure Cosmos DB API for NoSQL。深入了解適用於 MongoDB 的 Azure Cosmos DB API 中的索引編製

編製索引模式

Azure Cosmos DB 支援兩種索引編製模式：

一致：當您建立、更新或刪除項目時，索引會同步更新。意即讀取查詢的一致性將會是該帳戶所設定的一致性。
無：容器已停用索引編製。此模式通常用於當容器作為單純的索引鍵值存放區，而不需要次要索引時。此模式也可用於改善大量作業的效能。完成大量作業之後，索引模式可設為一致，接著使用 IndexTransformationProgress來監視至完成為止。

注意

Azure Cosmos DB 同時支援延遲索引模式。當引擎並未執行任何其他工作時，延遲索引會以較低的優先順序層級對更新執行索引。這可能會導致不一致或不完整的查詢結果。如果您打算查詢 Azure Cosmos DB 容器，則不應該選取延遲索引。新容器無法選取延遲索引。您可連絡 cosmosdbindexing@microsoft.com 要求豁免 (除非以不支援延遲索引的無伺服器模式使用 Azure Cosmos DB 帳戶)。

依預設，編製索引原則設為 automatic。將索引編製原則中的 automatic 屬性設為 true 即可。將此屬性設為 true，撰寫項目時 Azure Cosmos DB 便可自動編製索引。

索引大小

在 Azure Cosmos DB 中，已使用的總儲存體空間為資料大小和索引大小的加總。以下幾項為索引大小相關功能：

索引大小取決於索引編製原則。若所有屬性皆已編製索引，則索引大小可能大於資料大小。
刪除資料時，索引會以幾乎連續的方式進行壓縮。但刪除小型資料時，可能不會立即觀察到索引大小有所縮減。
分割實體分割區時，索引大小可能會暫時增加。分割區分割完成後，便會釋放索引空間。

包含和排除屬性路徑

自訂索引編製原則可指定索引編製時要明確包含或排除的屬性路徑。透過最佳化已編製索引的路徑數目，便可大幅降低寫入作業的延遲和 RU 費用。這些路徑會依索引編製概觀一節所述方法定義，並新增下列部分：

導向純量值 (字串或數字) 的路徑結尾為 /?
陣列的元素使用 /[] 標記法 (而不是 /0、/1 等方式) 一併處理
/* 萬用字元可用於比對節點下的任何元素

再舉相同範例：

    {
        "locations": [
            { "country": "Germany", "city": "Berlin" },
            { "country": "France", "city": "Paris" }
        ],
        "headquarters": { "country": "Belgium", "employees": 250 },
        "exports": [
            { "city": "Moscow" },
            { "city": "Athens" }
        ]
    }

headquarters 的 employees 路徑為 /headquarters/employees/?
locations 的 country 路徑為 /locations/[]/country/?
headquarters 下的任何路徑皆為 /headquarters/*

例如，我們可包含 /headquarters/employees/? 路徑。此路徑可確保編製員工 employees 屬性的索引，但不會在此屬性內編製額外巢狀 JSON 索引。

包含/排除策略

所有索引編製原則皆須包含根路徑 /*，作為包含或排除的路徑。

包含根路徑時，即可選擇性排除不需要編製索引的路徑。此為建議作法，如此 Azure Cosmos DB 便可主動為可能新增至模型的新屬性編製索引。
排除根路徑時，即可選擇性包含需要編製索引的路徑。根據預設，分割區索引鍵屬性路徑不會透過排除策略來編製索引，而且應該視需要明確包含。
針對具有一般字元 (含英數位元和 _ (底線) 的路徑)，無須使用雙引號逸出路徑字串 (例如 "/path/？")。針對具有其他特殊字元的路徑，則須使用雙引號逸出路徑字串 (例如 "/" path-abc "/？")。若預期路徑會有特殊字元，保險起見可逸出每個路徑。無論是逸出每個路徑，或只逸出具特殊字元的路徑，功能上皆無差異。
除非將 Etag 新增至包含的路徑進行索引編製，否則預設將排除系統屬性 _etag。
若索引編製模式設為一致，便會自動為系統屬性 id 和 _ts 編製索引。
如果項目中沒有明確編製索引的路徑，則會在索引中新增值來表示路徑未定義。

所有明確包含的路徑都會在容器中每個項目的索引中新增值，即使指定項目未定義路徑也一樣。

請參閱這一節，查看包含和排除路徑的編製索引原則範例。

包含/排除優先順序

若包含的路徑和排除的路徑有所衝突，則優先採用較為精確的路徑。

以下是範例：

包含的路徑：/food/ingredients/nutrition/*

排除的路徑：/food/ingredients/*

在此情況下，由於包含的路徑較為精確，因此優先順序高於排除的路徑。根據這些路徑，索引會排除 food/ingredients 路徑或巢狀內的所有資料。包含的路徑 /food/ingredients/nutrition/* 內資料則為例外，其會編製索引。

以下為 Azure Cosmos DB 中包含和排除路徑優先順序的幾項規則：

多層路徑比少層路徑更精確。例如：/a/b/? 比 /a/? 更精確。
/? 比 /* 更精確。例如 /a/? 比 /a/* 更準確，因此 /a/? 優先度較高。
此路徑 /* 須為包含的路徑或排除的路徑。

全文檢索索引

注意

您必須啟用 NoSQL API 預覽功能的全文檢索和混合式搜尋，才能指定全文檢索索引。

全文檢索索引可讓您使用索引有效率地進行全文搜索和評分。您可以在索引編製原則中定義全文檢索路徑，方法是包含索引編製原則的區 fullTextIndexes 段，其中包含要編製索引的所有文字路徑。例如：

{
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/*"
        }
    ],
    "excludedPaths": [
        {
            "path": "/\"_etag\"/?"
        },
    ],
    "fullTextIndexes": [
        {
            "path": "/text"
        }
    ]
}

重要

全文檢索索引原則必須位於容器全文檢索原則中定義的路徑上。深入了解容器向量原則。

向量索引

注意

您必須啟用 Azure Cosmos DB NoSQL 向量搜尋功能，以指定向量索引。

使用 VectorDistance 系統函式執行向量搜尋時，向量索引可提升效率。套用向量索引時，向量搜尋的延遲較低、輸送量較高，且 RU 耗用量較少。您可以指定下列類型的向量索引原則：

類型	描述	維度數上限
`flat`	將向量儲存在其他索引屬性的相同索引上。	505
`quantizedFlat`	量化 (壓縮) 向量，再儲存在索引上。這樣可以改善延遲和輸送量，代價是精確度降低。	4096
`diskANN`	根據 DiskANN 建立索引，進行快速且有效率的近似搜尋。	4096

請注意以下幾點：

flat 和 quantizedFlat 索引類型會在執行向量搜尋時，套用 Azure Cosmos DB 索引來儲存和讀取每個向量。使用 flat 索引的向量搜尋是暴力密碼破解搜尋，且會產生 100% 精確性或重新叫用。亦即，保證在資料集中尋找最類似的向量。不過，扁平索引上的向量有 505 維度限制。
- quantizedFlat 索引會將量化 (壓縮) 向量儲存在索引上。使用 quantizedFlat 索引的向量搜尋也是暴力密碼破解搜尋，但其精確度可能略低於 100%，因為向量在加入至索引之前會先量化。不過，使用 quantized flat 的向量搜尋相較於 flat 索引上的向量搜尋，其延遲應該會較低、輸送量更高，且 RU 成本較少。如果您要使用查詢篩選將向量搜尋的範圍縮小到相對較小的向量集，且需要高精確度時，這是一個很好的選項。
- diskANN 索引是不同的索引，專門針對套用 DiskANN 的向量定義，這是由 Microsoft Research 開發的高效能向量索引演算法套件。 DiskANN 索引可以提供最低延遲、最高輸送量和最低 RU 成本查詢，同時還能維持高精確度。不過，由於 DiskANN 是近似最近鄰項目 (ANN) 索引，因此精確度可能低於 quantizedFlat 或 flat。

diskANN和 quantizedFlat 索引可以採用選擇性的索引建置參數，可用來微調精確度與延遲取捨，而此取捨會套用至每個近似近鄰向量索引。

quantizationByteSize：設定產品量化的大小（以位元組為單位）。 Min=1，Default=dynamic （系統決定），Max=512。設定這個較大的值可能會導致較高的精確度向量搜尋，代價是較高的 RU 成本和更高的延遲。這同時 quantizedFlat 適用於和 DiskANN 索引類型。
- indexingSearchListSize：設定在索引建置建構期間要搜尋的向量數目。 Min=10，Default=100，Max=500。設定這個較大的值可能會導致較高的精確度向量搜尋，代價是較長的索引建置時間和更高的向量內嵌延遲。 DiskANN這僅適用於索引。

以下是具有向量索引的索引編製原則範例：

{
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/*"
        }
    ],
    "excludedPaths": [
        {
            "path": "/_etag/?",
        },
        {
            "path": "/vector/*"
        }
    ],
    "vectorIndexes": [
        {
            "path": "/vector",
            "type": "diskANN"
        }
    ]
}

重要

向量索引編製原則必須位於容器向量原則中定義的路徑。深入了解容器向量原則。

重要

已新增至索引編製原則的 "excludedPaths" 區段以確保插入效能最佳化的向量路徑。若未將向量路徑新增至 "excludedPaths"，將會導致向量插入的 RU 費用和延遲較高。

空間索引

在索引編製原則中定義空間路徑時，須定義應套用至該路徑的索引 type。空間索引的可能類型包括：

Point
Polygon
MultiPolygon
LineString

依預設，Azure Cosmos DB 不會建立任何空間索引。若要使用空間 SQL 內建函式，則應建立所需屬性的空間索引。請參閱此節，查看新增空間索引的索引編製原則範例。

Tuple 索引

元組索引在陣列元素內對多個字段執行篩選時很有用。 Tuple 索引定義於索引編製原則的 includedPaths 區段中，使用 Tuple 規範 “[]”。

注意

與包含或排除的路徑不同，您無法使用 /* 通配符建立路徑。每個 Tuple 路徑都必須以 “/？”結尾。如果 Tuple 路徑中的 Tuple 不存在於專案中，則會將值新增至索引，以指出 Tuple 未定義。

數位元 Tuple 路徑將會定義在 includedPaths 區段中，並且會使用下列表示法。

<path prefix>/[]/{<tuple 1>, <tuple 2> … <tuple n>}/?

請注意：

第一個部分「前置詞」是 Tuple 之間通用的路徑。它是從根目錄到陣列的路徑。在我們的範例中，它是 “/events”。
接下來是陣列通配符規範 “[]”。所有陣列元組路徑都應該在元組規範「{}之前具有數位通配符規範」。
接下來是使用 Tuple 規範「{}來指定 Tuple」。
Tuple 會以逗號分隔。
Tuple 必須使用與其他索引路徑相同的路徑規格，但有一些例外狀況：
Tuple 不應該以前置 “/” 開頭。
Tuple 不應該有陣列通配符。
Tuple 不應該結束 “？” 或 “*”
“?” 是 Tuple 路徑中的最後一個區段，應該緊接在 Tuple 規範區段之後指定。

例如，

/events/[]/{name, category}/?

以下是有效陣列 Tuple 路徑的一些範例：

    “includedPaths”:[  
        {“path”: “/events/[]/{name/first, name/last}/?”}, 
        {“path”: “/events/[]/{name/first, category}/?”}, 
        {“path”: “/events/[]/{name/first, category/subcategory}/?”}, 
        {“path”: “/events/[]/{name/[1]/first, category}/?”}, 
        {“path”: “/events/[]/{[1], [3]}/?”}, 
        {“path”: “/city/[1]/events/[]/{name, category}/?”} 
    ]

以下是無效陣列 Tuple 路徑的一些範例

/events/[]/{name/[]/first, category}/?
- 其中一個 Tuple 具有數位通配符
/events/[]/{name, category}/*
- 陣列 Tuple 路徑中的最後一個區段應該是 “？” 和不是 *
/events/[]/{{name, first},category}/?
- Tuple 規範是巢狀的
/events/{name, category}/?
- 元組規範之前遺漏陣列通配符
/events/[]/{/name,/category}/?
- Tuple 開頭為前置 /
/events/[]/{name/?,category/?}/?
- Tuple 結尾為 ?
/city/[]/events/[]/{name, category}/?
- 路徑前置詞為2陣組通配符

複合索引

若查詢的子句 ORDER BY 具有兩個以上的屬性，便需要複合式索引。您也可定義複合式索引，以改善許多相等和範圍查詢的效能。依預設，系統不會定義任何複合式索引，因此您應視需要新增複合式索引。

不同於包含或排除的路徑，您無法使用 /* 萬用字元來建立路徑。在無須指定的各複合路徑結尾，皆有隱含的 /?。複合路徑會導向純量值，且此為複合式索引中包含的唯一值。如果複合式索引中的路徑不存在於項目中或導致非純量值，則索引中會新增值來指出路徑尚未定義。

定義複合式索引時可指定：

兩個以上的屬性路徑。定義屬性路徑的序列很重要。
順序 (遞增或遞減)。

注意

新增複合式索引時，查詢會使用現有的範圍索引，直到新的複合式索引完成新增為止。因此新增複合索引時，可能不會立即觀察到效能有所改善。您可使用其中一個 SDK 來追蹤索引轉換的進度。

多個屬性的 ORDER BY 查詢：

搭配具有兩個或多個屬性的子句使用複合索引時 ORDER BY ，會使用下列考慮。

若複合式索引路徑與 ORDER BY 子句中的屬性序列不相符，複合式索引便無法支援查詢。
複合式索引路徑的順序 (遞增或遞減) 也應符合 ORDER BY 子句中的 order。
複合式索引也支援 ORDER BY 子句順序相反的所有路徑。

請見下列範例，針對名稱、年齡和 _ts 等屬性定義複合式索引：

複合式索引	範例`ORDER BY`查詢	複合式索引可支援嗎？
`(name ASC, age ASC)`	`SELECT * FROM c ORDER BY c.name ASC, c.age asc`	`Yes`
`(name ASC, age ASC)`	`SELECT * FROM c ORDER BY c.age ASC, c.name asc`	`No`
`(name ASC, age ASC)`	`SELECT * FROM c ORDER BY c.name DESC, c.age DESC`	`Yes`
`(name ASC, age ASC)`	`SELECT * FROM c ORDER BY c.name ASC, c.age DESC`	`No`
`(name ASC, age ASC, timestamp ASC)`	`SELECT * FROM c ORDER BY c.name ASC, c.age ASC, timestamp ASC`	`Yes`
`(name ASC, age ASC, timestamp ASC)`	`SELECT * FROM c ORDER BY c.name ASC, c.age ASC`	`No`

您應自訂索引編製原則，以便提供所有必要的 ORDER BY 查詢。

具有多屬性篩選條件的查詢

若查詢有兩個以上屬性的篩選條件，為這些屬性建立複合式索引則可能有所幫助。

例如，請見下列同時使用相等和範圍篩選條件的查詢：

SELECT *
FROM c
WHERE c.name = "John" AND c.age > 18

若能套用 (name ASC, age ASC) 的複合式索引，此查詢將可改善效率、縮短時間，且耗用更少 RU。

使用多個範圍篩選條件的查詢也可透過複合式索引最佳化。但每個個別的複合式索引僅可最佳化單一範圍篩選條件。範圍篩選包括 >、<、<=、>= 和 !=。在複合式索引中，範圍篩選條件應於最後定義。

請見下列查詢，使用一個相等篩選條件和兩個範圍篩選條件：

SELECT *
FROM c
WHERE c.name = "John" AND c.age > 18 AND c._ts > 1612212188

在 (name ASC, age ASC) 和 (name ASC, _ts ASC) 上使用複合式索引時，此查詢會更有效率。但該查詢的 (age ASC, name ASC) 不會使用複合式索引，因為使用相等篩選條件的屬性必須先在複合式索引中定義。由於各複合式索引僅可最佳化一個範圍篩選條件，因此 (name ASC, age ASC, _ts ASC) 必須使用兩個不同的複合式索引，而不是一個複合式索引。

針對使用多個屬性篩選條件的查詢建立複合式索引時，適用下列考量

篩選條件運算式可使用多個複合式索引。
查詢篩選條件中的屬性應符合複合式索引中的屬性。若複合式索引包含某屬性，但查詢未使用該屬性作為篩選條件，則查詢將不會使用複合式索引。
若查詢的篩選條件中有其他屬性未於複合式索引中定義，則會使用複合式索引和範圍索引的組合來評估該查詢。如此所需的 RU 會少於單獨使用範圍索引的情況。
若屬性具有範圍篩選條件 (>、<、<=、>= 或 !=)，則在複合式索引中應於最後定義此屬性。若查詢有一個以上的範圍篩選條件，多個複合式索引可能有所助益。
建立複合式索引來最佳化包含多個篩選準則的查詢時，複合式索引的 ORDER 不會影響結果。這個屬性為選擇性。

請見下列範例，針對名稱、年齡和時間戳記等屬性定義複合式索引：

複合式索引	範例查詢	複合式索引可支援嗎？
`(name ASC, age ASC)`	`SELECT * FROM c WHERE c.name = "John" AND c.age = 18`	`Yes`
`(name ASC, age ASC)`	`SELECT * FROM c WHERE c.name = "John" AND c.age > 18`	`Yes`
`(name ASC, age ASC)`	`SELECT COUNT(1) FROM c WHERE c.name = "John" AND c.age > 18`	`Yes`
`(name DESC, age ASC)`	`SELECT * FROM c WHERE c.name = "John" AND c.age > 18`	`Yes`
`(name ASC, age ASC)`	`SELECT * FROM c WHERE c.name != "John" AND c.age > 18`	`No`
`(name ASC, age ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.name = "John" AND c.age = 18 AND c.timestamp > 123049923`	`Yes`
`(name ASC, age ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.name = "John" AND c.age < 18 AND c.timestamp = 123049923`	`No`
`(name ASC, age ASC) and (name ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.name = "John" AND c.age < 18 AND c.timestamp > 123049923`	`Yes`

使用篩選和 ORDER BY 的查詢

若查詢使用一或多個屬性進行篩選，且 ORDER BY 子句中有不同屬性，將這些屬性加入 ORDER BY 子句便可能有所幫助。

例如，可將篩選的屬性加入 ORDER BY 子句，可重新撰寫下列查詢以套用複合式索引：

使用範圍索引的查詢：

SELECT *
FROM c 
WHERE c.name = "John" 
ORDER BY c.timestamp

使用複合式索引的查詢：

SELECT * 
FROM c 
WHERE c.name = "John"
ORDER BY c.name, c.timestamp

所有具有篩選條件的 ORDER BY 查詢皆適用於相同的查詢最佳化；請注意，個別複合式索引最多僅可支援一個範圍篩選條件。

使用範圍索引的查詢：

SELECT * 
FROM c 
WHERE c.name = "John" AND c.age = 18 AND c.timestamp > 1611947901 
ORDER BY c.timestamp

使用複合式索引的查詢：

SELECT * 
FROM c 
WHERE c.name = "John" AND c.age = 18 AND c.timestamp > 1611947901 
ORDER BY c.name, c.age, c.timestamp

此外，您也可使用複合式索引，以系統函式和 ORDER BY 來最佳化查詢：

使用範圍索引的查詢：

SELECT * 
FROM c 
WHERE c.firstName = "John" AND Contains(c.lastName, "Smith", true) 
ORDER BY c.lastName

使用複合式索引的查詢：

SELECT * 
FROM c 
WHERE c.firstName = "John" AND Contains(c.lastName, "Smith", true) 
ORDER BY c.firstName, c.lastName

使用篩選和 ORDER BY 子句建立複合式索引、最佳化查詢時，適用下列考量：

若含某屬性篩選條件的查詢未定義複合式索引，且有其他 ORDER BY 子句使用不同屬性，該查詢仍會成功。但使用複合式索引時可降低查詢的 RU 成本，特別是當子句 ORDER BY 中的屬性具有高基數時。
若查詢使用屬性來進行篩選，則 ORDER BY 子句中應先包含這些屬性。
若查詢使用多個屬性來進行篩選，則相等篩選條件須為 ORDER BY 子句中的第一組屬性。
若查詢使用多個屬性來進行篩選，各複合式索引最多可使用一個範圍篩選條件或系統函式。範圍篩選條件或系統函式中所用的屬性，應於複合式索引中最後定義。
使用多個屬性進行篩選的查詢、針對 ORDER BY 查詢建立複合式索引的所有考量仍適用。

複合式索引	範例`ORDER BY`查詢	複合式索引可支援嗎？
`(name ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.name = "John" ORDER BY c.name ASC, c.timestamp ASC`	`Yes`
`(name ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.name = "John" AND c.timestamp > 1589840355 ORDER BY c.name ASC, c.timestamp ASC`	`Yes`
`(timestamp ASC, name ASC)`	`SELECT * FROM c WHERE c.timestamp > 1589840355 AND c.name = "John" ORDER BY c.timestamp ASC, c.name ASC`	`No`
`(name ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.name = "John" ORDER BY c.timestamp ASC, c.name ASC`	`No`
`(name ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.name = "John" ORDER BY c.timestamp ASC`	`No`
`(age ASC, name ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.age = 18 and c.name = "John" ORDER BY c.age ASC, c.name ASC,c.timestamp ASC`	`Yes`
`(age ASC, name ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.age = 18 and c.name = "John" ORDER BY c.timestamp ASC`	`No`

使用篩選和彙總的查詢

若查詢使用一或多個屬性進行篩選，且使用彙總系統函式，在篩選條件和彙總系統函式中建立這些屬性的複合式索引便可能有所幫助。此最佳化適用於 SUM 和 AVG 系統函式。

透過篩選和彙總系統函式最佳化查詢時，適用下列考量。

使用彙總執行查詢時可選用複合式索引。但使用複合式索引時，通常可減少查詢的 RU 成本。
若查詢使用多個屬性來進行篩選，則相等篩選條件須為複合式索引中的第一組屬性。
各複合式索引最多可有一個範圍篩選條件，且須為彙總系統函式的屬性。
在複合式索引中，彙總系統函式中的屬性應於最後定義。
order (ASC 或 DESC) 並不重要。

複合式索引	範例查詢	複合式索引可支援嗎？
`(name ASC, timestamp ASC)`	`SELECT AVG(c.timestamp) FROM c WHERE c.name = "John"`	`Yes`
`(timestamp ASC, name ASC)`	`SELECT AVG(c.timestamp) FROM c WHERE c.name = "John"`	`No`
`(name ASC, timestamp ASC)`	`SELECT AVG(c.timestamp) FROM c WHERE c.name > "John"`	`No`
`(name ASC, age ASC, timestamp ASC)`	`SELECT AVG(c.timestamp) FROM c WHERE c.name = "John" AND c.age = 25`	`Yes`
`(age ASC, timestamp ASC)`	`SELECT AVG(c.timestamp) FROM c WHERE c.name = "John" AND c.age > 25`	`No`

具有陣列通配符的複合索引

以下是包含數位通配符的複合索引範例。

{  
    "automatic":true,
    "indexingMode":"Consistent",
    "includedPaths":[  
        {  
            "path":"/*"
        }
    ],
    "excludedPaths":[],
    "compositeIndexes":[  
        [  
            {"path":"/familyname", "order":"ascending"},
            {"path":"/children/[]/age", "order":"descending"}
        ]
    ]
}

可受益於此複合索引的範例查詢如下：

SELECT r.id
FROM root r
JOIN ch IN r.children
WHERE r.familyname = 'Anderson' AND ch.age > 20

修改編製索引原則

您可使用 Azure 入口網站或其中一個支援的 SDK，隨時更新容器的索引編製原則。更新索引編製原則時，即會觸發將舊索引轉換為新索引；此作業於線上和就地執行 (因此作業期間不會耗用額外儲存空間)。舊的索引編製原則會有效轉換為新原則，而不會影響寫入可用性、讀取可用性或容器所佈建的輸送量。索引轉換是非同步作業，完成所需的時間取決於佈建的輸送量、項目數及大小。如果必須進行多個編製索引原則更新，建議您將所有變更當做單一作業來執行，以便儘快完成索引轉換。

重要

索引轉換是取用要求單位和更新索引原則是 RU 系結作業的作業。如果遺漏任何索引編製字詞，客戶會看到耗用更多整體 RU 的查詢。

注意

您可在 Azure 入口網站中或使用其中一個 SDK 來追蹤索引轉換的進度。

任何索引轉換期間皆不會影響寫入可用性。索引轉換會使用您佈建的 RU，但優先順序低於 CRUD 作業或查詢。

新增索引路徑時不會影響讀取可用性。在索引轉換完成後，查詢才會使用新的索引路徑。意即新增索引路徑時，若查詢採用該索引路徑，索引轉換之前及期間的效能皆相同。索引轉換完成後，查詢引擎便會開始使用新的索引路徑。

移除索引路徑時，應將所有變更一次納入索引編製原則轉換作業。若在一次索引編製原則變更中移除多個索引，在整個索引轉換期間查詢引擎會提供一致且完整的結果。但若透過多次索引編製原則變更來移除索引，則在所有索引轉換完成前，查詢引擎不會提供一致或完整的結果。開發人員大多不會在卸除索引後，隨即又嘗試運用這些索引執行查詢，因此實務上這種情況發生的可能性不高。

卸除索引路徑時，查詢引擎將立即停止使用該路徑，改為進行完整掃描。

注意

如可能，應一律嘗試將多項索引移除納入單一項索引編製原則修改作業。

重要

移除索引會立即生效，而新增索引需要一些時間，因為需要索引轉換。將一個索引取代為另一個索引時 (例如，將單一屬性索引取代為複合式索引)，請務必先新增新的索引，然後等候索引轉換完成，再從索引編製原則中移除先前的索引。否則，這會對查詢上一個索引的能力造成負面影響，並可能會中斷任何參考上一個索引的作用中工作負載。

索引編製原則和 TTL

使用存留時間 (TTL) 功能時需要編製索引。這表示：

索引編製模式設為 none 的容器無法啟用 TTL，
啟用 TTL 的容器無法將索引編製模式設為 [無]。

若沒有需要編製索引的屬性路徑，但需要使用 TTL，則可使用索引編製原則，並將索引編製模式設為 consistent、無包含的路徑，且以 /* 作為唯一排除的路徑。

共用方式為

Azure Cosmos DB 中的索引編製原則

編製索引模式

索引大小

包含和排除屬性路徑

包含/排除策略

包含/排除優先順序

全文檢索索引

向量索引

空間索引

Tuple 索引

複合索引

多個屬性的 ORDER BY 查詢：

具有多屬性篩選條件的查詢

使用篩選和 ORDER BY 的查詢

使用篩選和彙總的查詢

具有陣列通配符的複合索引

修改編製索引原則

索引編製原則和 TTL

意見反應

其他資源

共用方式為

Azure Cosmos DB 中的索引編製原則

編製索引模式

索引大小

包含和排除屬性路徑

包含/排除策略

包含/排除優先順序

全文檢索索引

向量索引

空間索引

Tuple 索引

複合索引

多個屬性的 ORDER BY 查詢：

具有多屬性篩選條件的查詢

使用篩選和 ORDER BY 的查詢

使用篩選和彙總的查詢

具有陣列通配符的複合索引

修改編製索引原則

索引編製原則和 TTL

相關內容

意見反應

其他資源