🔁 主从复制原理
MySQL 主从复制是高可用和读扩展的基础，基于 binlog 实现数据同步。
复制流程
主库：将数据变更写入 binlog → 从库 IO 线程：读取主库 binlog 写入 relay log → 从库 SQL 线程：重放 relay log 应用到从库数据
binlog 格式对比
| 格式 | 内容 | 优缺点 |
|---|---|---|
| STATEMENT | 原始 SQL 语句 | 日志小，但某些函数（NOW()）有歧义 |
| ROW | 每行数据变化前后的值 | 可靠，但日志量大，推荐生产使用 |
| MIXED | 自动选择 | 兼顾两者，默认 |
-- 查看主库 binlog 状态
SHOW MASTER STATUS\G
-- 查看从库复制状态
SHOW SLAVE STATUS\G
-- 关键字段：Seconds_Behind_Master（复制延迟秒数）💡 MySQL 8.0 支持 GTID（全局事务标识）复制，比传统 binlog 位置复制更可靠，强烈推荐使用。
↔️ 读写分离
通过将读操作分流到从库，分散主库压力，提升系统整体吞吐量。
常用实现方案
| 方案 | 工具 | 特点 |
|---|---|---|
| 代理层 | ProxySQL、MySQL Router | 对应用透明，统一管理，推荐 |
| SDK 层 | ShardingSphere-JDBC | 嵌入应用，低延迟，Java 系常用 |
| 应用代码 | 手动配置多数据源 | 灵活但维护成本高 |
💡 注意主从复制延迟问题：刚写入主库的数据，从库可能还未同步，重要场景需强制读主库。
🛡️ 高可用方案
| 方案 | 原理 | 切换时间 | 适用场景 |
|---|---|---|---|
| MHA | 故障检测 + 自动切换 | 约 30s | 传统主从，成熟稳定 |
| MySQL InnoDB Cluster | MGR + MySQL Router + Shell | 约 5s | 官方推荐，8.0 首选 |
| Orchestrator | 可视化拓扑管理 | 约 30s | 大规模多集群管理 |
| 云 RDS | 云厂商托管 | 约 60s | 业务优先，运维少 |
📦 分库分表
当单表数据量超过 千万级 或单库 QPS 超过瓶颈时，需要考虑分库分表。
分片策略
| 策略 | 方式 | 优缺点 |
|---|---|---|
| Hash 分片 | id % N 路由到分片 | 分布均匀，但扩容需迁移数据 |
| Range 分片 | 按 ID/时间范围分片 | 扩容容易，但可能热点 |
| 目录分片 | 维护映射表 | 灵活，但映射表有瓶颈 |
💡 分库分表后会带来跨分片查询、分布式事务、全局唯一 ID 等新问题，需提前规划，不到万不得已不引入。
🔐 分布式事务
跨库操作需要保证数据一致性，常用方案：
| 方案 | 一致性 | 性能 | 说明 |
|---|---|---|---|
| 2PC（XA） | 强一致 | 低 | MySQL 原生支持，但性能差，锁时间长 |
| SAGA | 最终一致 | 高 | 通过补偿事务实现回滚，适合长事务 |
| 本地消息表 | 最终一致 | 高 | 基于 MQ，将事务拆成本地操作 + 消息 |
| Seata AT | 最终一致 | 中 | 框架自动生成 undo log，业务无侵入 |