分库分表到底该不该做？先看是不是真到了那一步
绝大多数 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，其余都正常。
