DynamoDB查询可传入的过滤器数量是否存在限制？

DynamoDB 相关规则与可行性 #

• DynamoDB 不存在类似 CloudSearch 的 1024个查询子句数量限制，但是有明确的单请求总大小约束：所有读写API的单请求payload上限为 16MB，请求中携带的筛选表达式、参数值列表长度全部计入这个大小统计。
• 如果你用FilterExpression的IN操作符匹配ID列表：IN本身没有硬编码的匹配值数量上限，只要整个请求体不超过 16MB 就不会抛出校验异常。以常见的36位UUID为例，1000个ID的总字符长度仅3.6万左右，加上其他请求参数总大小也只有几十KB，远低于16MB阈值，不会触发异常。
• 不推荐用Scan/Query + IN过滤的方式实现该需求：这种方式会执行全表或索引扫描，消耗额外读容量，性能和成本都很差。更合理的实现是用BatchGetItem接口直接按主键批量读取，该接口单次最多支持传入 100个 主键，你只需要把超过100个的ID列表拆分为多批次调用即可，不存在子句数量超限的问题。

Elasticsearch/OpenSearch 相关限制 #

• 这两个服务用于匹配多值的terms查询默认存在匹配项数量上限，由集群配置index.max_terms_count控制，默认值为 65536。1000个ID的列表远低于这个默认阈值，不会触发异常。如果后续ID规模超过65536，可以动态修改配置调大阈值，但不建议这么做：过长的ID列表会占用大量查询节点堆内存，容易引发GC停顿甚至节点OOM，这类超大规模ID匹配场景更适合用terms lookup机制，从索引内的文档中加载匹配值，不需要在请求中全量传递ID列表。
• 服务默认单HTTP请求体上限为 100MB，常规长度的ID列表基本不会触发这个限制，该阈值也支持通过配置调整。

选型参考 #

• 如果你的需求仅为按主键ID批量拉取记录，没有全文检索、多维度组合筛选、聚合分析等需求，直接选用DynamoDB，通过拆分BatchGetItem请求实现即可，稳定性和成本表现最优。
• 如果后续存在复杂搜索、聚合类需求，再考虑选用Elasticsearch/OpenSearch，1000个ID的查询规模在默认配置下可以稳定运行。

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