为什么同样的查询逻辑，在SQL里跑得好好的，搬到DynamoDB就慢得像在翻纸质档案？

这篇文章来自一位从关系型数据库转向DynamoDB的开发者实战记录。核心发现：DynamoDB不是"另一种SQL"，它的性能完全取决于你如何预先设计数据的访问路径。

打开网易新闻 查看精彩图片

正方：键值设计优先，放弃灵活查询

DynamoDB的设计哲学很明确——用查询驱动数据模型，而不是反过来。

传统关系型数据库允许你事后写任意查询。表结构定好后，业务变了？加条SQL就行。DynamoDB拒绝这种灵活性：你必须在创建表之前，就把应用需要的所有访问模式想清楚。

具体怎么做？

分区键（Partition Key）决定数据物理存储位置。想象成档案柜的抽屉标签——DynamoDB靠它直接定位，不用翻遍所有抽屉。每个表必须有且仅有一个分区键，通常是字符串或数字。

排序键（Sort Key，也叫Range Key）让同分区内的数据有序排列。字符串按字典序，数字按大小。组合起来，分区键+排序键构成唯一标识一条记录。

全局二级索引（Global Secondary Index，全局二级索引）是突破主键限制的工具。它让你用另一组键查询同一份数据，但代价是额外存储和写入开销。

作者提到两种GSI设计思路：

「合成键」（Synthetic Keys）是老办法——把多个属性拼接成一个字符串键，比如USER#123#ORDER#456。查询时用BeginsWith过滤。灵活但丑陋，键值语义藏在字符串里。

「多属性GSI」（Multi-Attribute GSIs）是新思路——把查询条件拆成独立的GSI属性，查询时直接等值匹配。代码更清晰，但需预先定义好查询模式。

正方论点总结：接受约束，换取性能。DynamoDB的单毫秒延迟不是免费的，它来自物理存储的精确预定位。

反方：扫描也能用，灵活查询有场景

完全放弃即席查询（ad-hoc query，即席查询）不现实。作者承认两种扫描的合理场景：

第一，后台任务或数据分析。不需要实时响应时，Scan操作遍历全表可以接受。配合ParallelScan还能多线程加速。

第二，小数据集。表只有几千行时，扫描成本可控。但作者警告：这是"今天"的小数据，业务增长后查询会突然变慢。

分页是另一个争议点。DynamoDB的分页基于"最后读取键"（LastEvaluatedKey），不是页码。用户界面常见的"跳到第7页"功能，DynamoDB原生不支持。

作者给出的方案：用Limit控制每页条数，缓存上一页的键。想跳页？只能逐页遍历。或者放弃精确页码，改用"加载更多"的无限滚动。

反方论点总结：扫描和复杂分页不是绝对禁止，但要清楚代价——延迟、成本和可扩展性天花板。

我的判断：迁移的本质是思维重构

作者最尖锐的观察藏在开头：

「如果你试图像用SQL那样用DynamoDB，它会反击你——而且你会输。」

这不是技术问题，是设计范式的冲突。关系型数据库卖的是"事后灵活性"，DynamoDB卖的是"预先优化的确定性"。

具体迁移建议：

第一步，列出应用的所有查询模式。不是"可能需要的"，是"现在就在用的"。每个查询必须能映射到分区键+可选排序键，或者GSI。

第二步，接受冗余。同一份数据按不同查询模式存多份，是DynamoDB的常规操作。没有JOIN，用反规范化（denormalization，反规范化）换读取性能。

第三步，警惕FilterExpression陷阱。它只在返回结果后过滤，不减少读取的数据量。成本高，延迟大，作者建议尽量把过滤条件放进键查询。

技术细节层面，文章提供了完整的.NET实现路径：安装AWSSDK.DynamoDBv2包，用对象持久化模型（Object Persistence Model，对象持久化模型）封装底层API，通过DynamoDBContext配置表映射。

一个实用的代码模式：多属性GSI的查询构造。把查询条件拆成独立的索引属性，避免字符串拼接的魔法值。

最终结论：DynamoDB的门槛不在API复杂度，而在设计决策的前置。适合查询模式稳定、访问量大的场景；不适合需求多变、需要复杂分析的工作负载。

作者最后补了一句：AWS CLI和Terraform的示例可以跳过，不影响理解核心概念——这对只想评估技术选型的读者很友好。

关系型思维的人看DynamoDB，总觉得少了点什么。后来才发现，少的那个东西叫"事后反悔权"。