去年双十一前两周，朋友电商订单库报警。 订单表 2.3 亿行，主库 32C64G，MySQL 8.0.32，NVMe 3TB，innodb_buffer_pool_size=40G。 凌晨 2 点 P99 从 90ms 冲到 1.7s，客服说用户点“我的订单”转圈。 我第一反应是上 ShardingSphere 5.4.1，分 16 库 64 表。 结果 pt-query-digest 一跑，排名第一的 SQL 是 select * from orders where user_id=? order by created_at desc limit 20，缺联合索引。 这事让我意识到：系统设计里最贵的不是机器，是你拍脑袋的决定。
当时峰值写 TPS 1200，读 QPS 9000，日订单 80 万，大促预测 3 倍。 单表 2.3 亿，热数据 90 天约 7200 万，占 31% 左右，冷数据其实可以归档。 加索引 (user_id, created_at desc, status) 后 P99 180ms，写入 TPS 从 1200 掉到 1104，降 8%。 但备份还是 4 小时，DDL 加字段用 gh-ost 7 小时，主从延迟 30s。 所以不是分库分表能治所有病，很多时候你只是缺一个索引和一个归档任务。
| 方案 | 写扩展 | 点查 P99 | 跨片聚合 | 事务 | 月成本 | 坑 |
|---|---|---|---|---|---|---|
| MySQL 8.0 读写分离 | 3000-5000 TPS | 10-30ms | 没跨片 | 本地事务 | 约 1.2 万 | 写瓶颈、DDL 锁 |
| ShardingSphere 5.4.1 分 16 库 64 表 | 4 万 TPS 理论 | 15-40ms | 麻烦 | 柔性事务 | 约 2.5 万 | 扩容、分布式事务 |
| TiDB 7.5 3PD+6TiKV | 2 万 TPS | 30-70ms | 支持 | 分布式事务 | 约 4 万 | 延迟抖动、成本 |
但表格是理想值，你线上有报表、join、库存扣减，P99 会变形。 我的独立观点：订单表先做“热冷分层 + 分区 + 索引”，别急着分库分表。分库分表是写扩展工具，不是查询加速器。 如果写 TPS 长期 > 6000，单表 > 2 亿，且冷热分离做完还压不住，再考虑分片。
1）开 slow_query_log=ON，long_query_time=0.1，跑 pt-query-digest，先抓 TOP 20。 2）用 sys.schema_table_statistics 看 rows_read、rows_changed，别凭感觉。 3）索引：覆盖索引，MySQL 8.0 没 include，就用联合索引，别 select *。 4）归档：pt-archiver 每次 1000 行，sleep 0.1，把 180 天前订单搬到 ClickHouse 或 S3 Parquet，主库从 2.3 亿降到 9000 万。 5）读写分离：ProxySQL 2.5.5，延迟阈值 5s，读流量 70% 走从库，报表单独走 OLAP。 6）还不行再分片：ShardingSphere-Proxy 5.4.1，分片键 user_id，order_id 用基因法后 4 位，避免 order_id 查询扫全部分片。 7）迁移双写 + binlog + 校验，采样 1% 对比，切读 1%→10%→50%→100%，写切换留 30 分钟回滚窗口。 这些步骤不酷，但能让你凌晨不用爬起来。
我们后来在另一个项目上了 TiDB 7.5，3 PD + 6 TiKV，单节点 16C64G，NVMe 2TB，Region 96MB。 好处是扩容简单，加 TiKV 就行，HTAP 报表直接在 TiDB 跑，不用同步到 ClickHouse。 坏处是点查 P99 比 MySQL 高，30-70ms 常见，大事务会打爆内存，成本是 MySQL 的 2.5-3 倍。 所以不是“新 SQL 一定香”，要看团队有没有人懂 PD 调度、TiKV 热点、GC。 我见过一个团队上 TiDB 后不会看 Region 热点，写热点全在一台，最后又换回 MySQL 分片。
系统设计不是选最牛组件，是在一致性、延迟、成本、团队能力之间做交换。 订单表 2 亿行，先问四个数：写 TPS、读 QPS、热数据比例、可接受 P99。 写 TPS < 3000、热数据 < 1 亿、P99 < 200ms，别分库分表，索引+归档+读写分离够用。 写 TPS > 6000、单表 > 2 亿、冷热分离后还顶不住，再上 ShardingSphere 或 TiDB。 分库分表最疼的不是代码，是以后加字段、扩容、跨片查询、对账。 这是我被大促教会的，不一定对，但比 PPT 上的架构图靠谱。
