mysql数据库中的分库分表策略与应用场景

分库分表不是首选优化手段，仅当单表超 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，其余都正常。