四年前只分了 4 片 现在单表 8000 万行 再扩容要停多久

上线时按日订单 2 万估了 4 个片，现在日均 30 万，单表 8000 万行，单表索引已经 6G，扩容方案评审三次还没定。日志里能对上时间点，这种反而好排。

分片数按当时的量算，没有留增长余量，两年就接近单表上限。扩容要重新分布全部历史数据，数据量越大停机窗口越长。这一点先确认清楚，后面就不用反复试。

SELECT table_name, table_rows, data_length/1024/1024 AS mb
FROM information_schema.tables
WHERE table_schema = 'order_db' ORDER BY table_rows DESC;

这次卡住的地方就在「分片数预估」这一环，单独把它拎出来验证，别和其他改动混在同一次发布里。先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。

别只看报错的最后一行，往上看几行，真正的起因通常在上面。

处理上按这个顺序：先按三年后的峰值算目标片数 一次分到位；用一致性哈希或预分片 减少后续迁移量；扩容做成双写加后台迁移 不占停机窗口；单表超过 5000 万行就启动扩容评估。

结果对不对很好判断，扩容方案能给出明确迁移时长 且业务停机不超过 10 分钟。