MySQL分库分表应在出现慢查询、主从延迟、DDL锁表等实际问题时启动，遵循业务驱动、渐进演进原则；适用场景包括单表超2000万行、写QPS超3000、存在大字段或天然隔离维度。
MySQL 分库分表不是“要不要做”，而是“什么时候做、怎么做得对”。核心原则是：业务驱动、渐进演进、避免过早设计。单库单表在千万级数据、QPS 百级以下通常完全够用；一旦出现慢查询频发、主从延迟严重、DDL 锁表时间过长、备份恢复困难等问题，才真正需要考虑拆分。
分库分表的典型适用场景
以下情况建议评估分库分表可行性：
- 单表数据量持续超过 2000 万行（InnoDB 引擎下，B+ 树层级加深，范围查询和 ORDER BY 性能明显下降）
- 单库写入 QPS 长期超过 3000（尤其高并发更新热点行，容易引发锁竞争和主从复制延迟）
- 核心业务表存在长期未优化的大字段或 JSON 字段（导致行变宽、缓冲池命中率低、复制流量大）
- 业务存在天然隔离维度（如多租户 SaaS 系统按 tenant_id 拆、电商按 shop_id 或 province 拆、游戏按 server_id 拆）
主流分片策略与选型建议
策略选择取决于查询模式和扩展性需求，没有银弹：
- 水平分表（Sharding）：同一逻辑表数据按规则分散到多个物理表。适合单表过大、读写集中于某类条件（如 user_id、order_no）。常用算法包括取模（简单但扩容难）、一致性哈希（扩容平滑但实现复杂）、范围分片（如按时间分月表，适合冷热分离但易倾斜）。
- 垂直分库：按业务域或读写特征拆分数据库。例如将用户中心、订单中心、支付中心独立成库。降低耦合，便于团队自治和独立扩缩容，但跨库 JOIN 和分布式事务需额外处理。
- 垂直分表：将宽表中访问频率差异大的字段拆到不同表（如 user_base 表存登录信息，user_ext 表存个人资料）。减少 I/O、提升缓存效率，常作为第一步轻量优化手段。
- 混合分片：生产环境常见组合——先垂直分库，再在核心库内水平分表（如订单库按 order_id 分 16 个子表）。
关键实现方式与技术选型
落地时优先考虑成熟方案，避免自研分片路由中间件：
- 客户端分片：应用层嵌入分片逻辑（如 ShardingSphere-JDBC）。轻量、无额外运维成本，但升级/变更需发布应用，SQL 兼容性依赖 SDK 版本。
- 代理层分片：使用 ShardingSphere-Proxy 或 MyCat。对应用透明，支持标准 MySQL 协议，适合遗留系统接入；但引入网络跳转、单点风险及连接池管理复杂度。
- 数据库内部分片（MySQL 8.0+ Clone Plugin + Group Replication）：官方仍在演进中，目前不推荐用于核心业务分片；TiDB、OceanBase 等 NewSQL 是替代选项，但属于架构级切换，需综合评估成本与收益。
- 务必配套建设：全局唯一 ID（Snowflake、号段模式或数据库号段表）、分布式事务（Seata AT 模式或本地消息表）、跨分片查询聚合（限制深度、走 ES 或宽表冗余）、分片键监控（数据分布是否倾斜）。
必须规避的典型陷阱
很多失败源于细节疏忽：
- 分片键选错：避免用 UUID 或随机字符串作分片键，会导致数据散列不均、范围查询失效；也慎用高频更新字段（如 status），引发跨分片更新。
- 忽略跨分片 JOIN 和排序：代理层虽支持，但性能差、内存消耗大。应尽量改造成两次查询（应用层组装）或预计算宽表。
- 全量扫描类操作裸奔：如 “SELECT * FROM order WHERE create_time > ‘2023-01-01’” 在无分片键条件下，会广播到所有节点，拖垮集群。
- 缺乏回滚能力：上线前必须验证反向迁移路径（如分片合并脚本）、影子库比对机制、慢日志采集覆盖分片后全链路。
