我有一个包含2个分区的16GB集合。当我通过ID查询文档时,速度非常慢。但是,如果按照索引字段查询,则速度很快。这两种方式都是跨分区查询,如果我在查询中传递分区键,则速度很快,但是我的查询并不总是有可用的分区键。使用.NET SDK和Azure Portal中的Document Explorer Query,得到了类似的结果。
该集合具有自定义索引策略,但据我所知,您无需对“Id”进行索引,甚至可能无法对其进行索引。
以下是我的查询及其相应的请求费用。
这表明按Id查询正在进行表扫描,因为大部分时间都花在了DocumentLoadTime上,而IndexLookupTime没有值。
但是根据@andrew-liu的答案,我认为Id应该是默认索引的主键。
该集合具有自定义索引策略,但据我所知,您无需对“Id”进行索引,甚至可能无法对其进行索引。
以下是我的查询及其相应的请求费用。
SELECT * FROM c where c.id = 'unique-id-123'
-- Request Charge: 344940.79 RUs, Document Count: 1
SELECT * FROM c WHERE c.otherId = 'NOT-so-uniqueId-123'
-- Request Charge: 5.08 RUs, Document Count: 3
正如您所知,标识符是唯一的,因此查询将返回1个文档,而第二个查询被otherId
过滤,这不是很唯一,并返回3个文档。同时请注意第一次查询的极高RUs消耗。
那么为什么第二个查询比按Id更快呢?
更新:
下面是上述查询的指标。
按Id查询:
Read 1 records in 1497 ms, 339173.109 RU, Size: 6873022 KB
QueryPreparationTime(ms): CompileTime = 2, LogicalBuildTime = 0,
PhysicalPlanBuildTime = 0, OptimizationTime = 0
QueryEngineTime(ms): DocumentLoadTime = 1126, IndexLookupTime = 0,
RuntimeExecutionTimes = 356, WriteOutputTime = 0
按索引字段查询:
Read 4 records in 2 ms, 7.56 RU, Size: 9 KB
QueryPreparationTime(ms): CompileTime = 0, LogicalBuildTime = 0,
PhysicalPlanBuildTime = 0, OptimizationTime = 0
QueryEngineTime(ms): DocumentLoadTime = 0, IndexLookupTime = 1,
RuntimeExecutionTimes = 0, WriteOutputTime = 0
这表明按Id查询正在进行表扫描,因为大部分时间都花在了DocumentLoadTime上,而IndexLookupTime没有值。
但是根据@andrew-liu的答案,我认为Id应该是默认索引的主键。