Azure Cosmos DB 中的索引編製原則

適用於: 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 帳戶)。

索引大小

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

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

附註

資料分割索引鍵 (除非它也是 "/id") 未編製索引，而且應該包含在索引中。

當 Cosmos 帳戶編製索引模式為「一致」時，系統屬性識別碼和 _ts 一律會編製索引
系統屬性標識碼和_ts不包含在容器原則的索引路徑描述中。這是設計方式，因為這些系統屬性預設會編製索引，因此無法停用此行為。

包含和排除屬性路徑

自訂索引編製原則可指定索引編製時要明確包含或排除的屬性路徑。透過最佳化已編製索引的路徑數目，便可大幅降低寫入作業的延遲和 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：設定產品量化的大小 (以位元組為單位)。最小值=1，預設值=動態 (系統決定)，最大值=512。將此項設定得更大可能會導致更高準確性的向量搜尋，但代價是更高的 RU 成本和更高的延遲。這適用於 quantizedFlat 和 DiskANN 索引類型。
- indexingSearchListSize：設定在索引建置建構期間要搜尋的向量數目。最小值=10，預設值=100，最大值=500。將此項設定得更大可能會導致更高準確性的向量搜尋，但代價是更長的索引建置時間和更高的向量內嵌延遲。這僅適用於 DiskANN 索引。

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

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

重要事項

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

空間索引

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

Point
多邊形
MultiPolygon
LineString

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

Tuple 索引

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 不應以“?”結尾或 “*”
“?” 是 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}/?
- Tuple 指定符號之前遺漏了陣列萬用字元
/events/[]/{/name,/category}/?
- Tuple 以 / 開頭
/events/[]/{name/?,category/?}/?
- Tuple 以 ? 結尾
/city/[]/events/[]/{name, category}/?
- 路徑前置詞含有 2 個陣列萬用字元

複合式索引

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

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

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

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

附註

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

多個屬性的 ORDER BY 查詢：

若查詢包含的子句 ORDER BY 具有兩個以上的屬性，使用複合式索引時則有下列考量。

若複合式索引路徑與 ORDER BY 子句中的屬性序列不相符，複合式索引便無法支援查詢。
複合式索引路徑的順序 (遞增或遞減) 也應符合 order 子句中的 ORDER BY。
複合式索引也支援 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，隨時更新容器的索引編製原則。更新索引編製原則時，即會觸發將舊索引轉換為新索引；此作業於線上和就地執行 (因此作業期間不會耗用額外的儲存空間)。舊的索引編製原則會有效轉換為新原則，而不會影響寫入可用性、讀取可用性或容器所佈建的輸送量。索引轉換是非同步作業，完成所需的時間取決於佈建的輸送量、項目數及大小。如果必須進行多個編製索引原則更新，建議您將所有變更當做單一作業來執行，以便儘快完成索引轉換。

重要事項

索引轉換作業會耗用要求單位。

附註

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

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

新增索引路徑時不會影響讀取可用性。在索引轉換完成後，查詢才會使用新的索引路徑。換句話說，當新增一個已建立索引的路徑時，受益於該已建立索引路徑的查詢在索引轉換之前和期間具有相同的效能。索引轉換完成後，查詢引擎便會開始使用新的索引路徑。

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

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

附註

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

重要事項

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

索引編製原則和 TTL

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

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

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

意見反應

此頁面對您有幫助嗎？

Last updated on 2025-09-19

共用方式為

Azure Cosmos DB 中的索引編製原則

索引編製模式

索引大小

包含和排除屬性路徑

包含/排除策略

包含/排除優先順序

全文索引

向量索引

空間索引

Tuple 索引

複合式索引

多個屬性的 ORDER BY 查詢：

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

使用篩選和 ORDER BY 的查詢

使用篩選和彙總的查詢

具有陣列萬用字元的複合式索引

修改編製索引原則

索引編製原則和 TTL

相關內容

意見反應

其他資源