mysql 高可用面试要点

一、主从复制类

Q1：MySQL 主从复制的原理是什么？

1. 主库把变更写入 binlog。

2. 从库 IO 线程连接主库，主库 dump 线程把 binlog 发给从库。

3. 从库 IO 线程写入 relay log。

4. 从库 SQL 线程重放 relay log，应用到从库数据。

核心：一个主库 dump，两个从库线程（IO + SQL）。

Q2：主从复制的三种模式？

Q3：半同步复制怎么工作？

• 主库提交后，等至少一个从库确认收到 binlog（不一定重放完）才返回。

• 超时会退化为异步。

• 参数：rpl_semi_sync_master_enabled、rpl_semi_sync_master_timeout。

• 减少丢数据风险，但增加延迟。

Q4：主从延迟的原因有哪些？

• 从库 SQL 线程单线程重放，主库并发写。

• 大事务、DDL、批量操作。

• 从库硬件差、压力大。

• 网络延迟。

• 主库写入量超过从库重放能力。

Q5：怎么解决主从延迟？

• 并行复制：slave_parallel_workers、slave_parallel_type=LOGICAL_CLOCK。

• 拆分大事务，避免批量。

• 提升从库硬件。

• 读己之写：写后短时间读主。

• 半同步、MGR。

• 监控 Seconds_Behind_Master。

Q6：主从延迟导致读到旧数据怎么办？

• 读己之写：用户写后一段时间内读主库。

• 记录 binlog 位点，等从库追上再读。

• 关键业务强制读主。

• 用半同步减少延迟。

Q7：主从复制怎么保证数据一致？

• binlog 格式用 ROW。

• 半同步或 MGR。

• 从库 read_only=ON，防误写。

• 校验工具：pt-table-checksum、pt-table-sync。

二、读写分离类

Q8：读写分离怎么做？

• 主库写，从库读。

• 实现方式：

  • 中间件：ShardingSphere、MyCat、ProxySQL。

  • 客户端：应用层配置多数据源。

  • 驱动层：如 MySQL Router。

• 核心：SQL 路由，写走主，读走从。

Q9：读写分离有什么问题？

• 主从延迟导致读到旧数据。

• 事务内读写要同库。

• 路由规则复杂，如 SELECT ... FOR UPDATE 要走主。

• 从库故障要能切换。

Q10：读写分离和分库分表能一起用吗？

• 可以。分片后每个分片再配主从。

• 中间件同时处理分片路由和读写分离。

• 复杂度高，需统一规划。

三、分库分表类

Q11：为什么要分库分表？

• 单表数据量过大，B+ 树变高，查询慢。

• 单库连接数、磁盘、CPU 到瓶颈。

• 写入量大，单库扛不住。

Q12：垂直拆分和水平拆分的区别？

Q13：分片键怎么选？

• 分布均匀，避免热点。

• 高频查询能命中分片键。

• 常用：user_id、order_id、时间。

• 避免用区分度低或易变的列。

Q14：分片算法有哪些？

• 哈希取模：均匀，但扩容要迁移。

• 范围：易扩容，但可能热点。

• 一致性哈希：扩容影响小。

• 雪花 ID 嵌入分片：如 user_id 取模。

• 常用 基因法：把分片键嵌入 ID。

Q15：分库分表后的问题？

1. 跨库 JOIN：冗余字段、广播表、应用层组装。

2. 分布式事务：2PC、TCC、Saga、本地消息表。

3. 全局 ID：雪花算法、号段、Redis。

4. 跨库分页：归并排序，或二次查询。

5. 扩容：一致性哈希、双写迁移。

Q16：全局 ID 怎么生成？

Q17：跨库分页怎么处理？

• 每个分片取 offset + limit 条，归并排序取前 limit。

• 深分页用游标或二次查询。

• 禁止跨库 JOIN 和复杂聚合。

Q18：分库分表后怎么扩容？

• 双写迁移：新旧库双写，逐步切流量。

• 一致性哈希：减少迁移量。

• 基因法：按分片键定位，便于扩容。

• 工具：ShardingSphere、gh-ost、pt-online-schema-change。

四、高可用方案类

Q19：MySQL 高可用方案有哪些？

Q20：MHA 的原理？

• Manager 监控主库，主库故障时选最接近的从库提升为主。

• 其他从库重新指向新主。

• 配合 VIP 或中间件切换。

• 有脑裂风险，需 fencing。

Q21：MGR 是什么？

• MySQL Group Replication，基于 Paxos。

• 多节点组成组，多数派确认。

• 支持单主和多主模式。

• 强一致，但网络要求高，性能略低。

Q22：怎么避免脑裂？

• 用多数派投票（MGR）。

• 加 fencing 机制，隔离旧主。

• VIP 切换配合健康检查。

• 设置 read_only、super_read_only。

Q23：故障切换怎么保证不丢数据？

• 半同步或 MGR，确保从库收到 binlog。

• 选位点最新的从库提升。

• 切换前确认 relay log 重放完。

• 监控和演练。

五、分布式与一致性类

Q24：分布式事务有哪些方案？

Q25：最终一致性和强一致性的区别？

• 强一致：任何时刻读到最新数据，性能差。

• 最终一致：短时间不一致，最终一致，性能好。

• 互联网高并发常用最终一致。

Q26：怎么保证缓存和数据库一致？

• 先更新 DB，再删缓存（Cache Aside）。

• 延迟双删。

• 订阅 binlog 更新缓存（Canal）。

• 强一致用分布式锁或事务。

Q27：CAP 和 BASE 是什么？

• CAP：一致性、可用性、分区容忍，三选二。

• 分布式系统 P 必须，所以 C 和 A 取舍。

• BASE：基本可用、软状态、最终一致。

六、监控与容灾类

Q28：MySQL 监控哪些指标？

• QPS、TPS、连接数、活跃线程。

• 主从延迟 Seconds_Behind_Master。

• 慢查询数、锁等待、死锁。

• Buffer Pool 命中率、磁盘 I/O。

• 工具：Prometheus + mysqld_exporter、Zabbix。

Q29：怎么做容灾？

• 同城双活、异地多活。

• 主从 + 多副本。

• 定期备份 + binlog 归档。

• 演练切换和恢复。

Q30：备份策略怎么定？

• 全量 + 增量：每周全量，每天增量。

• 工具：XtraBackup、mysqldump。

• binlog 归档，支持时间点恢复。

• 定期恢复演练。

七、高频陷阱题

Q31：主从复制是强一致吗？

• 默认异步，不是。

• 半同步接近，但只保证收到，不保证重放。

• MGR 多数派确认，强一致。

Q32：读写分离后写后立即读会怎样？

• 可能读到旧数据，因主从延迟。

• 解决：读己之写，关键读走主。

Q33：分库分表后 COUNT(*) 怎么办？

• 各分片求和。

• 用计数表或缓存。

• 避免实时精确统计。

Q34：分库分表后自增 ID 冲突吗？

• 会。需全局 ID 或设置不同步长。

• 推荐雪花算法或号段模式。

Q35：MHA 和 MGR 怎么选？

• MHA：成熟、简单，但非强一致，有脑裂风险。

• MGR：强一致、自动选主，但网络要求高、性能略低。

• 金融级选 MGR，一般业务 MHA 或云 RDS。