DynamoDB PartiQL查询比普通Query命令容量消耗更高的原因

• 首先明确你使用的GSI as_of_when-the_url-index-2 的键结构：分区键为as_of_when，排序键为the_url。DynamoDB原生Query API有强语法约束：
  • 所有针对主键属性（含基表、GSI的分区键、排序键）的判断逻辑，必须写在KeyConditionExpression中，不允许将主键属性放入FilterExpression做过滤
  • KeyConditionExpression仅支持对排序键做等值判断、大小比较、BETWEEN、begins_with这类前缀/范围匹配操作，完全不支持contains这类非前缀匹配的函数判断
• 你执行的无过滤原生Query仅消耗1CU，是因为原生Query默认单次请求只返回第一页结果，那次请求刚好只读取了索引分区的第一个4KB数据块（1个读Capacity Unit对应1次强一致读4KB数据，或2次最终一致读4KB数据），属于标准的键定位查找行为。如果手动翻完该分区键下所有索引页的全部数据，总CU消耗会和实际扫描的数据总大小完全对应。
• PartiQL语句消耗66CU的核心原因有两个：
  • 你在WHERE子句中对索引排序键the_url使用了not contains函数，这个操作不属于键条件支持的合法操作，直接导致查询优化器无法走键范围裁剪路径，退化为逐行扫描逻辑：从该索引分区的起始位置开始，读取每一条索引项判断是否匹配条件，总共扫描了66个4KB大小的索引块，对应66CU的消耗。注意DynamoDB的读CU是按实际从存储读取的数据量计算，和过滤后返回多少条数据无关，哪怕99%的条目被not contains过滤掉，读这些条目产生的CU也会被全额计算。
  • aws dynamodb execute-statement命令默认会隐式完成全部分页拉取，自动遍历完所有匹配的结果，不会像原生Query默认只返回第一页结果，因此会把整个扫描过程的CU全部统计进来。

PartiQL的查询优化器是固定规则驱动，没有基于数据统计的代价估算逻辑，判断走键查找还是全扫描的规则非常明确：

• 仅当WHERE子句中对键属性的判断完全符合键条件约束时，才会生成和原生Query一致的高效执行计划：
  • 对分区键必须是直接的等值判断，不能用函数包裹分区键属性
  • 对排序键只能使用=、<、<=、>、>=、BETWEEN、begins_with这几类合法操作，且不能用函数包裹排序键属性
    满足以上条件时，PartiQL会先按分区键定位到对应索引/表分区，再按排序键条件做范围裁剪，CU消耗和原生Query完全一致。
• 只要WHERE子句中出现任何不符合上述规则的写法——比如对键属性使用contains、lower、size等函数，或者对键属性做算术/字符串运算——优化器就无法生成键查找计划，直接退化为全量扫描逻辑：
  • 如果语句中指定了索引，就扫描对应索引的全量数据；如果未指定索引，就扫描基表全量数据
  • 扫描过程中逐行判断所有WHERE条件，匹配的条目才会返回，这个过程不会做任何分区、排序键范围的裁剪，CU消耗和扫描的总数据量完全正相关，很容易出现超出预期的成本。
• PartiQL本身没有原生Query那样的语法拦截逻辑，不会因为你对键属性使用了不合法的过滤函数就直接报错，只会默默降级为扫描执行，这也是很多用户用PartiQL时成本超预期的核心原因。

注：如果确实需要对排序键做contains类的过滤，没有高效的直接查询方案，只能先通过键条件拉取对应分区下的全量数据，再在业务层做过滤，或者提前在写入时把需要过滤的特征拆解成单独的属性，配合稀疏索引实现高效查找。

内容的提问来源于stack exchange，提问作者HSchmale