MySQL 的知识点很多，容易散成一堆面试问答。把它们串起来，可以从四条线看：复制链路、存储引擎、日志体系和查询优化。
主从复制靠 binlog 和 relay log 串起来
MySQL 主从复制的基本流程可以拆成三个角色。
主库把数据变更写入 binlog。从库 I/O 线程拉取主库 binlog，写入自己的 relay log。从库 SQL 线程再读取 relay log，把变更重放到本地。
这套机制说明了几个常见问题：
- 主从延迟本质是重放速度跟不上写入速度。
- 主库压力、网络抖动、从库慢 SQL 都可能放大延迟。
- 做读写分离时，必须考虑读到旧数据的可能性。
如果业务要求写后立刻读到最新值，要么读主库，要么设计读自己写策略。
InnoDB 和 MyISAM 的边界很清楚
现在大多数业务默认选择 InnoDB，因为它支持事务、行级锁、MVCC、崩溃恢复和更完整的并发能力。MyISAM 的历史价值更多体现在表锁、简单读多写少场景和一些老系统兼容上。
常见差异可以这样记：
- InnoDB 支持事务，MyISAM 不支持。
- InnoDB 默认行级锁，MyISAM 是表级锁。
- InnoDB 支持 MVCC，适合高并发读写。
- MyISAM 曾经在
count(*)等场景有一些结构性优势，但不适合作为现代业务默认选择。
选择引擎不是看单点性能，而是看一致性、并发和故障恢复要求。
日志决定可靠性和排障能力
MySQL 里常见日志包括错误日志、慢查询日志、binlog、relay log、redo log 和 undo log。
binlog 面向复制和恢复，记录逻辑变更；redo log 面向崩溃恢复，保证已提交事务持久化；undo log 支持回滚和 MVCC；慢查询日志帮助定位耗时 SQL；错误日志用于看启动、崩溃和运行异常。
事务提交时先写日志再写数据，这种预写日志思想是数据库可靠性的关键。
SQL 优化从执行计划开始
遇到慢 SQL，先看 EXPLAIN，不要凭感觉加索引。
重点关注：
type：访问方式，越接近 const、ref、range 通常越好。key：实际使用了哪个索引。key_len：索引使用长度，能看出复合索引用到哪一段。rows：预计扫描行数。Extra：是否出现 filesort、temporary、using index 等信息。
索引不是越多越好。索引会占空间，也会拖慢写入和维护。只有能显著减少扫描范围、排序成本或回表成本的索引才值得保留。
运维问题要有固定动作
数据库 CPU 飙高时，先看当前连接和正在执行的 SQL，再看慢日志、错误日志、磁盘 I/O 和锁等待。不要第一时间重启数据库。
备份也要按恢复目标设计。逻辑备份易迁移但恢复慢，物理备份更适合大库。除了备份成功，还要定期验证恢复速度和恢复完整性。
主从一致性可以用校验工具定期检查。字符集要提前统一，尤其是需要 emoji 或多语言时，优先使用 utf8mb4。
实用结论
MySQL 架构不是零散命令集合。复制负责扩展读取和容灾，日志负责可靠性和恢复，存储引擎决定事务与锁能力，索引和执行计划决定查询成本。
排查 MySQL 问题时，先判断它属于哪条线，再动手处理。这样比记一堆孤立命令更稳。
