水平扩展MySQL本质是加机器分流量，核心是分散读写压力并保障数据一致性和可用性；它应对连接数暴涨、QPS突增、存储见顶等瓶颈，而非优化慢查询；典型路径为读写分离→垂直拆分→水平分片或单元化。
水平扩展 MySQL 本质是“加机器分流量”，不是单机调优，核心思路是把一个库的读写压力分散到多个节点上，同时保障数据一致性和业务可用性。它不解决慢查询或索引问题，而是应对连接数暴涨、QPS 突增、存储容量见顶等典型高并发瓶颈。
读写分离：最常用且见效快的起点将主库（Master）专用于写操作，多个从库（Replica/Slave）承担读请求，天然缓解主库压力。关键点在于：应用层需识别读写语句，或借助中间件（如 MyCat、ShardingSphere、ProxySQL）自动路由；
注意主从延迟（seconds_behind_master），对强一致性读（如刚下单查订单）需强制走主库或加等待逻辑；
从库可分级：近端从库处理实时性要求高的读，远端从库做报表或分析类查询。
分库分表：突破单机容量与性能天花板当单表超千万行、单库超百 GB 或写入 QPS 持续超过 3000+，就该考虑拆分。重点不在“怎么拆”，而在“按什么逻辑拆”：垂直拆分：按业务域切，比如用户库、订单库、商品库，各自独立部署，减少耦合和锁竞争；
水平拆分：同一张表数据按规则打散，常见策略有：按 user_id 取模、按时间范围（如 order_202401）、按地理区域（shard by province）；
必须配套全局唯一 ID 方案（如雪花算法、号段模式），避免自增主键冲突；
跨分片 JOIN、分布式事务、count/group by 等聚合操作会变复杂，建议从业务层面规避或用异步汇总替代。
多主架构与单元化：面向超大规模业务的进阶选择适用于全球化部署或极端高并发场景（如秒杀、支付核心），但运维复杂度陡增：MySQL（Linux）
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载多主（Multi-Master）需解决双向同步冲突，推荐用基于 GTID 的半同步 + 冲突检测插件（如 MySQL Group Replication 或 Percona XtraDB Cluster），但写热点仍存在；
单元化（Cell / Shard Unit）是更彻底的方案：每个单元包含完整业务闭环（用户+订单+支付），按用户 ID 哈希路由到固定单元，实现物理隔离和故障收敛；
单元间仅允许异步消息通信（如 Kafka），禁止跨单元强一致写，最终一致性由业务兜底。
配套能力不可少：没有银弹，只有组合拳光加机器不够，必须同步升级支撑体系：连接池管理：应用侧用 HikariCP 等高性能池，控制最大连接数，避免打爆数据库；
缓存前置：Redis 缓存热数据（如用户资料、商品详情），降低 DB 查询频次，注意缓存穿透/雪崩/击穿防护；
监控告警：重点关注主从延迟、慢查询堆积、线程连接数、复制错误、磁盘 IO 等指标；
灰度发布与回滚能力：分库分表上线必须支持按用户比例灰度，失败时能快速切回旧路径。
不复杂但容易忽略。水平扩展不是一步到位，而是根据业务增长节奏逐步推进：先读写分离 → 再垂直拆分 → 最后按需水平分片或单元化。每一步都要有可观测性、可回退性和业务协同。