DynamoDB与类SQL数据库对比：扫描性能、GSI相关问题咨询

1. Scan操作与类SQL数据库查询的性能差异 #

• DynamoDB Scan：本质是全表/全索引遍历，会读取所有分区的项目，不管是否符合筛选条件。数据量越大，性能下降越明显——不仅消耗大量读容量单位（RCU），跨分区扫描还会带来更高的延迟，且默认分页返回（最多1MB数据），大规模扫描需要多次请求拼接结果。
• 类SQL查询：如果依赖合适的索引（主键、二级索引），会直接定位到目标数据所在的存储块，性能稳定且延迟低；即使是SQL的全表扫描，因为关系型数据库通常是单节点或集群内本地存储，遍历效率也比分布式的DynamoDB Scan高，尤其是数据量较大时。

简单说：小数据量下两者差异不大，但数据量上去后，Scan的性能会断崖式下跌，而SQL带索引的查询基本能保持稳定。

2. Scan操作的适用场景 #

Scan并非完全没用，这些场景下它是合理选择：

• 小数据量场景：比如测试环境的小表（几百条数据），用Scan比建GSI更省事，性能差异可忽略。
• 全表数据导出/备份：需要获取所有数据时，Scan是最直接的方式（配合LastEvaluatedKey做增量扫描，避免单次请求过载）。
• 无合适索引的临时查询：如果需要筛选的属性没建索引，且数据量不大，临时用Scan比紧急创建GSI更高效（GSI创建需要时间同步数据）。
• 批量数据处理：比如数据迁移、批量更新所有符合条件的项目，用Scan配合分页逐步处理，适合低频的后台任务。

3. GSI映射所有项目属性的弊端不止占用存储 #

全属性投影的GSI有这些额外问题：

• 写入性能损耗：主表每写入/更新一条数据，GSI也要同步写入全量属性，会消耗双倍甚至更多的写容量单位（WCU），拖慢主表的写入速度，尤其是高并发场景。
• 数据一致性延迟：GSI的同步是最终一致性的，全属性投影意味着同步的数据量更大，可能导致更长的延迟，查询GSI时容易读到 stale data。
• 成本上升：除了存储成本，WCU的消耗增加也会直接提升运营成本，长期下来是一笔不小的开支。
• 资源浪费：很多投影的属性可能根本用不到，白白占用存储和同步资源，反而增加了GSI的维护复杂度。

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