当单表行数超2000万或.ibd文件超50gb、qps长期超8000、连接数频繁打满、慢查询无法通过索引优化解决、ddl变更已严重影响线上稳定性时，且已排除常规优化手段，应启动分库分表评估。
不需要凭感觉，也不用等系统崩了再动手。只要满足以下任一条件，且已排除索引、SQL、缓存等常规优化手段，就该启动分库分表评估。
单表行数超2000万或.ibd文件超50GB
这两个指标是硬门槛，但得结合实际负载看：
-
SELECT COUNT(*)结果持续超过2000万行，且B+树高度已升至4层（SHOW INDEX FROM table_name中Cardinality与行数比值明显下降） -
ls -lh /var/lib/mysql/db/table.ibd显示文件大小突破50GB（SSD环境可放宽到100GB，但需确认Innodb_buffer_pool_hit_ratio长期低于95%） - 执行
ALTER TABLE ADD COLUMN耗时超过30分钟，或OPTIMIZE TABLE根本无法在业务窗口内完成 - 注意：如果表里3年前的数据占70%以上，优先用
PARTITION BY RANGE (create_time)分区，而不是直接分表
QPS长期超8000或连接数频繁打满
这是判断“该分库”的关键信号，和单表数据量无关：
-
SHOW STATUS LIKE 'Threads_connected'值经常接近max_connections（生产环境建议设为1000，不是默认151） - 监控中
Innodb_row_lock_time_avg> 50ms，且Innodb_deadlocks每小时增长超5次 - 出现
Too many connections错误，或应用层连接池报Connection timeout - 写QPS（
Com_insert + Com_update + Com_delete）稳定在3000以上，尤其集中在几个热点行（如库存表的stock_id = 1001）
慢查询无法靠索引和改写解决
很多团队跳过这步就拆，结果新架构跑着更慢：
- 用
EXPLAIN FORMAT=JSON确认高频SQL是否已走覆盖索引，rows_examined是否远大于rows_sent - 存在强依赖
ORDER BY created_at LIMIT 20但分片键是user_id——这种查询在分库分表后会变成N次查询+内存合并，延迟翻倍 - 慢日志里TOP 5 SQL都缺失确定的分片键条件（如没有
WHERE order_id = ?），或含跨分片JOIN、SELECT * - 如果
pt-query-digest输出中Full_scan占比超30%，先做垂直分表或字段裁剪，别急着水平拆
DDL变更已实质影响线上稳定性
这不是触发条件，而是危险红灯：
- 加索引、改字段必须卡在凌晨2–4点，且每次操作期间主库CPU/IO持续90%+，备库延迟飙升至小时级
- 即使用了
gh-ost或pt-online-schema-change，也不敢在10:00–22:00高峰期执行 - 备份窗口拉长到6小时以上，
mysqldump或mydumper经常失败，xtrabackup流式备份流量压垮网卡 - 此时优先升级到MySQL 8.0（支持原子DDL、不可见索引），或把分析类查询导出到ClickHouse，而不是立刻分库分表
真正容易被忽略的是：分库分表后，你得自己承担原本由MySQL内置机制处理的事——比如跨分片事务一致性、全局唯一ID生成、分页排序合并逻辑。这些不是配置开关，而是要写进业务代码里的硬成本。
