SELECT merchant_id, count(*) c FROM t_order WHERE create_time >= '2026-11-11' GROUP BY merchant_id ORDER BY c DESC LIMIT 10;
大促开始十分钟，ds_07 的 CPU 到 96%，写入 QPS 4200，其余 15 个片都在 300 上下，这个片上的订单几乎全来自同一个大商户。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。
原因不复杂，分片键用商户 id，头部商户的订单量是普通商户的几十倍，哈希之后仍然集中在同一个片。片内连接数和锁竞争跟着放大，慢查询开始堆积。
「热点分片」排查到最后往往是很小的一处差异，前面那些复杂猜测可以先放一放。备份不是备了就行，恢复一次才算数，很多备份文件打开才发现是空的。
接口问题先分清是没发出去、发出去了没收到，还是收到了处理失败。
处理上按这个顺序：按商户维度统计订单量 找出头部占比；对头部商户的键加后缀拆成多个虚拟片 查询时合并；热点商户单独迁到独立库 不和长尾混用；给该片加只读副本 把报表查询分出去。
改完只确认一件事：头部商户的写入分散到 4 个片 单片 CPU 回落到 60% 以下。