DynamoDB GSI查询能否用contains作为键条件及是否触发全扫描

核心结论 #

你写的KeyConditionExpression: contains (GSI, :val1) and contains(GSI, :val2)表达式完全无法在Query接口中正常执行，不管你查询的是基表还是自建GSI，请求发起后会直接触发参数校验错误被拒绝，根本不会进入实际查询执行阶段，自然也谈不上走索引还是全表扫描。

规则说明 #

DynamoDB对Query操作的键条件表达式有强约束，没有变通空间：

• 所有索引（含基表主键、GSI、LSI）的分区键（HASH键）仅支持精确等值匹配，合法写法只有分区键字段名 = :绑定参数值，contains、begins_with、大小比较、范围匹配类的运算符/函数都不能用在分区键条件上。
• 如果索引配置了排序键（RANGE键），排序键仅支持=、<、<=、>、>=、between、begins_with这几类条件，contains函数从设计上就不允许出现在KeyConditionExpression的任何位置，无论作用在分区键还是排序键上。

实现多值包含匹配的实际表现 #

contains函数仅允许被写在FilterExpression中。要注意FilterExpression不参与索引定位，它的作用是Query通过合法键条件捞出一批数据后，在返回结果前做内存层面的结果过滤，不会减少实际扫描的索引数据量。
如果你要实现“GSI字段同时包含val1、val2”的查询逻辑，且不调整现有数据模型，只能使用Scan操作，把两个contains条件写在FilterExpression里——这种写法就是标准的全表（或全GSI）扫描，会遍历对应表/索引的每一条数据，数据量越大消耗的读吞吐量越高、延迟越高，成本也会随数据量线性上涨，生产环境大表下严禁这么用。

如果需要高频执行这类多关键词包含匹配，建议提前调整数据建模方案：比如把待匹配的字段提前做分词，拆分后的单个关键词作为GSI分区键单独存储，查询时通过多个精确键匹配取结果交集，才能真正命中GSI索引，避免全表扫描。

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