MySQL分库分表是解决单机数据库性能瓶颈的核心方案，主要应对数据量过大和高并发访问两大问题。以下是系统化的技术解析与实践指南：

一、核心概念

1. 分库

   • 垂直分库：按业务模块拆分（如用户库、订单库、商品库）
   • 水平分库：将同一表数据按规则分布到多个数据库（如按user_id哈希）

2. 分表

   • 垂直分表：将大表列拆分（如热点字段与冷字段分离）
   • 水平分表：单表数据按规则拆到多个子表（如按月份分表）

二、典型场景

三、分片策略（关键设计）

1. 哈希分片

   shard_key = user_id % 1024  -- 分配到1024个分片
   

   优点：数据均匀分布
   缺点：扩容需数据迁移

2. 范围分片

   CREATE TABLE orders_2024 (
     id BIGINT,
     ...
   ) PARTITION BY RANGE (YEAR(create_time)) (
     PARTITION p2024 VALUES LESS THAN (2025)
   );
   

   优点：按时间范围查询高效
   缺点：可能产生热点数据

3. 地理位置分片
   华北用户 → 北京机房，华南用户 → 深圳机房

四、技术方案对比

五、核心挑战与解决方案

1. 分布式ID生成

   • Snowflake算法：64位ID（时间戳+机器ID+序列号）
   • 数据库号段：每次从DB获取ID段缓存使用

2. 跨分片查询

   -- 非分片键查询需聚合结果（如查用户所有订单）
   SELECT * FROM orders_00 UNION ... UNION SELECT * FROM orders_99 
   WHERE user_id=123;
   

   优化：建立异构索引库（如ES同步订单数据）

3. 分布式事务

   • XA事务：强一致但性能低（2PC协议）
   • 柔性事务：
     • SAGA模式：事务拆分为子任务补偿
     • TCC模式：Try/Confirm/Cancel三阶段

4. 数据迁移

   • 双写方案：新老库同步写入，增量数据迁移后切换

六、最佳实践

1. 避免过度拆分：初始按32/64分片预留空间
2. 分片键选择：高频查询字段（如user_id）且数据均匀
3. 冷热分离：3年前订单转存至ClickHouse
4. 监控：重点监控分片倾斜率（如某分片超均值50%需调整）

七、何时需要分库分表？

• 数据量预警：单表超5000万行或磁盘占用70%以上
• 性能瓶颈：CPU持续>80%或查询响应超500ms
• 业务需求：需多地机房部署降低延迟

注：优先考虑优化SQL、索引、缓存、读写分离，分库分表是最后手段！

八、演进路线建议

通过合理的分库分表设计，可支撑系统从百万级到亿级用户的平滑扩展。关键是根据业务特性选择分片策略，并配套解决分布式带来的新问题。