分库分表不是“拆着玩”，而是为扛住真实并发和数据量
分库分表是当单库单表撑不住业务增长时，把数据**物理分散到多个数据库或多个表中**的手段。它不改变逻辑语义（比如你查
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在拖慢整体。
