你有没有碰到过这种情况：看监控，整个表才用了不到10%的吞吐量，结果请求还是被拒得一塌糊涂。不是云厂商偷扣你的配额，是热分区这东西太会藏——DynamoDB自适应容量号称能救，但一堆人把它当万能灵药，最后连分区上限在哪都不知道，照样被限。

这里面的机制其实就三板斧：突发容量、自适应容量、还有就是那个冷冰冰的分区上限。搞不清这三者的关系，等于是闭着眼做键设计。下面直接拆成五条，一个一个看。

一、分区上限，谁求情都没用。
DynamoDB每个分区每秒硬限3000读和1000写。注意，不是预留也不是配置，是物理顶棚——无论你是按需还是预留模式，都一样。SQL出身的喜欢看服务器整体负载，DynamoDB这里却是按分区限流，哪怕99%的分区闲得发慌，一个热键就能把整个表掐住。

二、突发容量只能兜五分钟的底。
分区没吃满的吞吐量不会被浪费，后台会帮你攒起来，最多能蓄五分钟的量。突然来个短脉冲，它能把这些积蓄花掉，让你暂时超出每秒限额。但账算得很清，攒的不够你就别怪它。而且这玩意儿看不见、调不了，系统自己也可能偷偷用掉一部分，拿它当常备余量，迟早翻车。

三、自适应容量才是扛偏斜的主力。
突发容量管的是瞬间，自适应容量盯的是持续的热。比如你用车联网表，分区键VEHICLE#ID，某个配送车在闪购区发出十倍于同伴的遥测数据，它的分区烫得不行，其他车的分区却空转。自适应容量这时会从冷分区抽走余量，喂给那个热分区，不用你做任何调整，也没额外费用，2019年5月以后连热身的延迟都免了。

四、极致热点会被单独拎出来。
如果某个键实在太火，DynamoDB甚至会把它隔离进独立分区，这样它就能吃满一整颗分区的全部能力，也就是3,000读或1,000写每秒。听着很香吧？但别高兴太早，这已经是它能给的极限了。

五、键设计烂，神仙也救不了。
自适应容量再怎么搬，也逃不出分区上限的五指山。真正热到突破天花板，整个分区无余量可借，限流照来不误。用自适应容量不是让你从此不理键设计，而是告诉你：在分区上限之内，它能帮你抹平偏斜，想靠它越狱，门都没有。