分库分表不是首选优化手段，仅当单表超2000万行、主从延迟>30s、慢查询集中或磁盘使用率≥85%且无法扩容时才需评估；过早实施会引入跨库JOIN、分布式事务等复杂问题。
分库分表到底该不该做？先看是不是真到了那一步
绝大多数 MySQL 应用根本不需要分库分表——它不是性能优化的第一选择，而是容量和扩展性走到瓶颈后的被动决策。当单表行数持续超过 2000 万、主从延迟长期 > 30s、慢查询集中在某张大表、或者单实例磁盘使用率逼近 85% 且无法扩容时，才值得认真评估分库分表。
过早分库分表会直接引入跨库 JOIN、分布式事务、全局 ID、数据迁移、一致性校验等复杂问题，代价远高于加索引、读写分离或升级硬件。
垂直拆分：按业务边界切库，不是按字段乱分
垂直拆分本质是解耦，核心是识别「高内聚、低耦合」的业务域。比如电商系统中，user、order、product 三张表天然属于不同子域，应拆到不同数据库（如 db_user、db_order、db_product），而不是把 user 表的 name 和 address 拆到两个库。
- 拆分后应用层必须明确每个 DAO 只操作对应库，不能在
db_user里查order数据 - 跨库关联查询只能靠应用层两次查询+内存拼接，或同步冗余关键字段（如订单表存
user_name） - 注意外键约束失效：MySQL 的外键只在单库生效，拆库后需靠应用逻辑或最终一致性保障
水平分表：选对分片键比选算法更重要
水平分表的关键不是哈希还是取模，而是分片键（sharding key）是否具备高查询离散性、低关联性、不可变性。例如用户中心场景，用 user_id 分片合理，但用 create_time 就会导致热点（新数据全写入最新分片）。
常见分片策略对比：
-
hash(user_id) % N：简单，但扩容需迁移大量数据 -
range by create_time（如按月分表order_202401、order_202402）：范围查询快，但易产生冷热不均 - 一致性哈希：节点增减影响小，但 MySQL 原生不支持，需中间件（如
ShardingSphere或MyCat）实现
务必避免用 UUID 或随机字符串作分片键——它们导致写入完全随机，丧失局部性，严重拖慢 insert 性能。
分库分表后，这些坑几乎人人踩
分库分表不是加个中间件就完事，很多隐性成本在上线后才爆发：
-
count(*)、order by + limit、group by等聚合操作必须由中间件合并结果，性能下降明显，且容易内存溢出 - 没有全局唯一 ID：自增主键在分表后失效，必须改用
雪花算法（snowflake）、UUID（需去重）或独立发号服务 - 跨分片事务无法用 MySQL 原生
XA保证强一致，实际多采用本地消息表 + 最终一致性方案 - 备份与恢复变复杂：单库备份脚本失效，需并行拉取所有分片，并确保时间点一致
最常被忽略的一点：分库分表后，DBA 的监控粒度必须下钻到每个物理分片——你看到的「主从延迟 1s」，可能是某个分片延迟了 60s，其余都正常。
