分库分表是为解决单表超千万行导致查询变慢、索引失效及单库连接数/IO/CPU瓶颈而将数据物理分散的手段；水平分库分摊资源压力但牺牲事务与JOIN，水平分表保事务却未解实例级瓶颈；需先验证真实瓶颈，慎选分片策略与键。
分库分表不是“拆着玩”，而是为扛住真实并发和数据量
分库分表是当单库单表撑不住业务增长时，把数据**物理分散到多个数据库或多个表中**的手段。它不改变逻辑语义（比如你查 user 表，还是写那条 SQL），但背后数据已不在一个地方了——这是为解决两个硬瓶颈：一是单表超 1000 万行后查询变慢、索引失效、ALTER TABLE 卡死；二是单库连接数打满（Too many connections）、CPU 或磁盘 IO 持续 90%+，主从同步延迟飙升。
水平分库 vs 水平分表：关键看压力来源在哪
两者都按「行」切，结构完全一致，区别只在切的粒度：
-
水平分表：同一库内建
user_0、user_1… 多张结构相同的表，用user_id % 4路由。适合单表太大（如日志表达 200GB）、但并发不高、写入集中在少数库的场景。优点是不跨库，事务仍可用；缺点是没缓解连接数和 CPU 压力，因为还在一个 MySQL 实例里。 -
水平分库：把
user表数据按user_id哈希后，分别存到shard0、shard1等不同 MySQL 实例。真正分摊连接、IO、CPU。但代价是跨库事务难做，JOIN和GROUP BY需中间件聚合，比如 MyCat 或 ShardingSphere。
别一上来就分库——先确认是不是真需要。用 SHOW PROCESSLIST 看有没有大量 Sending data 或 Copying to tmp table on disk 状态；用 SELECT COUNT(*) 和 EXPLAIN 验证单表是否真成瓶颈。很多团队误把慢查询归咎于数据量，其实是没加索引或写了 SELECT *。
哈希取模最常用，但扩容时得提前想好路由规则
按 user_id % 4 分 4 个库/表，简单直接，数据也均匀。但问题来了：业务涨了，要扩到 8 个库，原来 user_id=5 在库 1（5%4=1），现在 5%8=5，得把这条数据搬过去——全量迁移成本极高。
- 推荐用一致性哈希（如
md5(user_id) % 1024），新增节点只影响相邻虚拟节点的数据，迁移量可控； - 或者预分片（pre-sharding）：一开始就按 1024 个逻辑分片设计，物理上先用 4 台机器各管 256 片，后续扩容只需调整映射，不动数据；
- Range 分片（如按时间分
order_202501、order_202502）看似好扩容，但极易热点——所有新订单都写最新表，该表磁盘 IO 直接打满。
MyCat 的 rule.xml 或 ShardingSphere 的 sharding-algorithm 配置里，必须明确定义分片键（sharding key）和算法，且这个字段要在所有相关 SQL 的 WHERE 条件里出现，否则路由失败，变成全库广播查询。
垂直拆分常被忽略，但它能立刻缓解连接数和缓存压力
垂直分库是按业务切，比如把 user_info、user_profile 放 user_db，把 user_order、user_payment 放 order_db。它不解决单表大问题，但能：show variables like 'max_connections' 查出默认 151 连接，拆成两个库后，每个库独立计数，总连接能力翻倍；高频访问的用户基础信息表更小，InnoDB Buffer Pool 缓存命中率上升。
- 拆之前先梳理依赖：原来一条
JOIN user_info ON u.id = o.user_id的 SQL，现在得改成应用层两次查询 + 组装； - 字典表（如
region、status_type）建议冗余到各库，避免跨库关联； - 外键约束在分库后失效，得靠应用层或分布式事务（如 Seata）兜底。
真正的难点不在怎么切，而在切完之后怎么让开发不感知、DBA 不崩溃、监控不丢指标——比如分库后慢查询日志得聚合分析，performance_schema 要按分片维度采集，否则你根本不知道是哪个 shard2 在拖慢整体。
