信息技术大学
日志与优化
计算机基础面试八股 · 第 3 章 数据库（MySQL 与 Redis）
按 空格/→ 演示下一步
全部页面点击任意一页，跳回舞台从这页播放
信息技术大学
日志与优化
计算机基础面试八股 · 第 3 章 数据库（MySQL 与 Redis）
redo/undo/binlog 分工
三本账各司其职：redo 保崩溃不丢，undo 保可回滚，binlog 保主从与归档。
redo log
InnoDB 物理日志，先写后改，崩溃后重放恢复
undo log
反向操作日志，回滚与 MVCC 都靠它
binlog
Server 层逻辑日志，主从复制与归档恢复
层次
redo/undo 属引擎层，binlog 属服务层
两阶段提交
redo 与 binlog 是两本账，两阶段提交保证「要么都写成，要么都没写」。
prepare
redo 先写入并落盘，事务标记 prepare
commit
写完 binlog 后，redo 再改标 commit
崩溃裁决
恢复时比对两本账状态，杜绝不一致
EXPLAIN 执行计划
EXPLAIN 是 SQL 的透视镜：type 与 key 看走没走索引，rows 是预估扫描量。
type
const/eq_ref/ref/range 递减，index 与 ALL 要警惕
key/rows
实际选用的索引与预估扫描行数
Extra
Using index 是覆盖，Using filesort 要留心
慢查询定位与优化套路
先抓慢 SQL 再对症下药：索引、改写、限范围，三板斧解决八成问题。
抓取
慢查询日志定位，pt-query-digest 聚类分析
索引优化
EXPLAIN 看计划，补索引、防失效
SQL 改写
深分页改游标式，SELECT * 换按需取列
架构兜底
读写分离、缓存、分库分表层层接力
本节要点
- ✓redo 崩溃重放，undo 回滚，binlog 复制
- ✓两阶段提交对齐两本账
- ✓EXPLAIN 定性：type/key/rows/Extra
- ✓慢 SQL：先抓取，再索引，后改写
延伸主题：EXPLAIN 一条线上慢 SQL确认 binlog 格式配置
课后思考
先自己回答，再展开参考答案——能讲出来才算真懂。
1有了 redo log 为什么还要 binlog？两者不都在记录修改吗？
参考答案redo 是引擎层的物理页修改日志，服务崩溃恢复，循环写会覆盖；binlog 是 Server 层逻辑日志，服务复制与时间点恢复，追加不覆盖。一个管「重启后数据对」，一个管「上下游数据齐」。
2两阶段提交崩溃后，MySQL 如何裁决事务状态？
参考答案恢复时扫描比对：redo 处于 prepare 且 binlog 完整，则提交；binlog 不完整则回滚。以 binlog 为准，因为它是主从复制的唯一依据，两边必须一致。
3LIMIT 1000000,10 为什么慢，怎么改？
参考答案深分页要扫描并丢弃前一百万行；改成游标式分页 WHERE id > 上次末尾 LIMIT 10，靠索引直接定位起点，扫描量与页深无关。