MySQL集群扩容以水平扩展为主，通过分库分表、读写分离、Group Replication或云托管服务实现；需兼顾一致性、可用性与业务特征，关键在分片设计、灰度迁移、延迟控制及压测验证。
MySQL 集群扩容主要靠水平扩展（Scale Out），即增加节点分担读写压力，而不是升级单机配置（Scale Up）。核心思路是把数据拆分、流量分流，同时保障一致性与可用性。实际落地需结合业务读写特征、一致性要求和运维能力来选型。
分库分表（Sharding）是最主流的水平扩展方式
适用于数据量大、QPS高、且能接受一定复杂度的业务场景。本质是将单库单表的数据按规则（如用户ID取模、时间范围、地理区域等）分散到多个物理库表中。
- 应用层分片：由业务代码或 SDK 控制路由逻辑，轻量但侵入性强，维护成本随分片数上升明显
- 中间件分片：使用 ShardingSphere-JDBC、MyCat 或 Vitess 等代理层统一管理分片规则和 SQL 路由，对应用透明，支持读写分离、自动扩容重平衡（部分支持）
- 扩容操作关键点：新增节点后需迁移历史数据，建议用双写+校验+切流方式灰度迁移；避免停服，注意全局唯一 ID（推荐雪花算法或数据库号段模式）
读写分离 + 多从库横向扩展读能力
适合读多写少场景（如资讯、电商详情页），不改变数据分布，只扩展查询吞吐。
- 主库负责写入和强一致性读，多个从库通过异步/半同步复制承接读请求
- 可基于负载、延迟、权重等策略做读负载均衡；注意从库延迟导致的“读到旧数据”问题，关键业务需强制走主库
- 扩容只需加从库并加入负载池，无需迁移数据，但写能力仍受限于主库单点
MySQL Group Replication / InnoDB Cluster 支持弹性扩缩容
基于 Paxos 协议的高可用集群方案，天然支持多写（Multi-Primary 模式）或单写（Single-Primary 模式），节点增减可在线进行。
- 新增节点通过 SST（全量同步）或 IST（增量同步）自动拉取数据，加入集群后参与选举与负载分担
- 需确保网络稳定、时钟同步、GTID 开启；节点数建议为奇数（3/5），避免脑裂
- 不解决单表过大问题，仅提升可用性与读扩展性；写扩展有限（Multi-Primary 模式下需避免跨节点事务热点）
云托管服务简化扩容流程（如阿里云 PolarDB、腾讯云 TDSQL）
底层已封装分片、读写分离、自动扩缩容逻辑，用户通过控制台或 API 调整规格或节点数即可触发后台调度。
- 适合中小团队或快速上线项目，免运维但成本略高，兼容性需提前验证（如存储过程、自定义函数支持度）
- 部分服务支持“计算与存储分离”，扩容计算节点几乎秒级生效，存储可独立线性扩展
- 注意厂商锁定风险，迁移回自建 MySQL 可能涉及数据格式、权限模型、监控体系重构
不复杂但容易忽略：所有水平扩展方案都绕不开数据一致性、分布式事务、跨节点 JOIN 和聚合查询的妥协。上线前务必压测真实业务 SQL，尤其关注分片键设计是否导致热点，以及扩容窗口期的数据同步可靠性。
