MySQL分片集群是系统性工程，适用于单库单表逼近性能极限（如用户表超500万行、日增订单超10万条）的场景，核心目标是分散读写压力、提升扩容灵活性，需统筹数据分布、请求路由与一致性保障。
搭建 MySQL 分片集群不是简单加机器，而是围绕数据分布、请求路由和一致性保障做系统性设计。它适用于单库单表已逼近性能极限（如用户表超 500 万行、日增订单超 10 万条）的业务场景，核心目标是把“一个大锅饭”拆成“多个小灶台”，让读写压力分散、扩容更灵活。
明确分片类型与适用场景
分片分两种：垂直拆分按业务切库，水平拆分按数据切表。实际中常组合使用。
-
垂直分库：适合模块边界清晰的系统。比如把 user、auth、profile 表放进
user_db，order、cart、payment 放进order_db。好处是解耦强、迁移成本低，但跨库 JOIN 和事务需上层协调。 -
水平分表/分库：适合单表膨胀快的场景。例如用用户 ID 哈希值对 8 取模，把
user表拆成user_0到user_7共 8 张表，再分别部署在不同物理库中。关键是要选好分片键（如 user_id、order_no），确保数据分布均匀、查询能精准落库。
选择分片中间件并配置基础路由
不建议在应用层硬编码分片逻辑，推荐使用成熟中间件统一管理路由规则。
-
ShardingSphere-JDBC（轻量嵌入式）：适合 Java 应用，通过配置文件定义分片策略，SQL 透明改写。例如设置
t_user表按user_id % 8分片，自动将SELECT * FROM t_user WHERE user_id = 12345路由到对应子表。 - Mycat（代理型）：独立部署，对应用无侵入。需配置 schema.xml 定义逻辑库、分片规则；server.xml 设置登录账号；rule.xml 编写分片算法（如 mod-long、date-partition）。它会把客户端发来的 SQL 解析后转发到真实节点。
- 注意点：无论哪种方案，都要禁用全局自增主键，改用分布式 ID（如雪花算法、TinyID 或数据库号段模式），避免插入冲突。
处理分片后的典型难题
分片带来扩展性，也引入新复杂度，必须提前应对：
-
跨分片查询：SUM、AVG、ORDER BY LIMIT 等聚合操作无法下推到单个节点时，中间件会拉取所有结果再内存合并。应尽量避免深分页（
LIMIT 10000,20），改用游标分页或冗余汇总表。 - 分布式事务：跨库更新必须保证一致性。优先用最终一致性（如基于消息队列的本地事务+补偿），强一致场景可选 Seata 的 AT 模式（需业务表加 undo_log）或 XA（性能损耗大，慎用）。
- 扩容重平衡：从 8 分片扩到 16 分片时，部分数据要迁移。Mycat 支持在线扩容，ShardingSphere 提供 DistSQL 命令辅助迁移。务必在低峰期操作，并做好全量校验与回滚预案。
配套高可用与监控不可少
分片集群节点多，任何一个出问题都可能影响局部服务，因此不能只关注分片本身。
- 每个物理 MySQL 实例仍需主从复制（至少一主一从），保障单节点故障可切换；
- 用 ProxySQL 或 HAProxy 做读写分离 + 健康探活，避免把请求发给已宕机的分片节点；
- 接入 Prometheus + Grafana，重点监控各分片的 QPS、慢查数、复制延迟、连接数，设置阈值告警；
- 定期用 pt-table-checksum 校验主从数据一致性，用 pt-online-schema-change 在线改分片表结构。
分片不是银弹，它解决的是规模瓶颈，但也提高了运维和开发门槛。上线前建议先在测试环境模拟百万级数据压测，验证路由准确性、聚合性能和故障转移时效。真正落地时，往往是“小步快跑”：先垂直拆分，再水平分片，最后补上分布式事务和弹性伸缩能力。
