2000万行是B+树索引从3层升至4层、I/O翻倍的典型临界信号，判断是否需水平拆分应先验证是否真卡在单表：EXPLAIN显示type=ALL或rows远超返回行数、SHOW PROFILE中Creating sort index耗时突增等，仅当加索引、调参等轻量手段失效时才启动拆分。
2000万不是性能拐点的精确刻度，而是B+树索引在常见业务配置下从3层升到4层、I/O开销翻倍的典型临界信号。真要拆，别先写分库分表代码，先确认是不是真卡在单表——比如EXPLAIN显示type=ALL或rows远超实际返回行数，或者SHOW PROFILE里Creating sort index或Copying to tmp table on disk耗时突增。
怎么判断该水平拆分而不是加索引或调参？
水平拆分是重操作，只有当轻量手段失效才上：
-
WHERE条件字段已有二级索引，但EXPLAIN仍走全表扫描（说明统计信息不准或索引选择率差） - 高频查询出现深分页：
LIMIT 5000000, 20执行超2秒，且ORDER BY无法命中覆盖索引 -
ALTER TABLE ADD COLUMN卡住超过5分钟，SHOW PROCESSLIST看到大量Waiting for table metadata lock - 主从延迟持续>30秒，且
SHOW SLAVE STATUS中Seconds_Behind_Master波动剧烈，同时innodb_row_lock_time_avg明显升高
按什么字段分片最不容易翻车？
选分片键的核心是“让查询尽量落到单个分片”，而不是“数据均匀”。常见踩坑是拿id或create_time硬分，结果热点写入+范围查询跨分片：
- 优先用业务天然隔离维度：SaaS系统用
tenant_id，电商订单用shop_id，游戏日志用server_id - 避免用自增
id：会导致新数据全写入最后一个分片，热点和扩容都难 - 慎用时间字段：按
create_time月分片后，查“最近7天”要扫1~2个分片，但查“2025年全年”就得扫12个 - 如果必须用
user_id，确保其分布足够离散（比如MD5(user_id)取后4位做分片），否则小号段用户集中导致数据倾斜
ShardingSphere-JDBC接入时最关键的三个配置项
不用改业务SQL，但application.yml里这三项配错，90%的慢查询会原样复现：
-
sharding-column必须和SQL中WHERE条件字段完全一致（大小写敏感），比如配置了sharding-column: user_id，但代码里写WHERE userId = ?，就会全路由 -
algorithm-expression里别用%取模：分片数一变就要迁移全部数据；改用INLINE表达式配合sharding-jdbc的standard算法，支持动态扩容 -
props.sql-show上线前务必设为false：开启后每条SQL都会触发额外日志序列化，QPS超1000时CPU直接拉满
真正麻烦的从来不是拆分动作本身，而是拆完后那堆隐性依赖：跨分片JOIN得改应用层组装，全局唯一ID得换SNOWFLAKE或LEAF，分页查询得用游标替代LIMIT offset。这些不提前对齐，上线当天就会发现监控里sharding-sphere.route.time指标突然飙升——不是分片逻辑慢，是应用还在按单库思维发SQL。
