慢查询与性能分析
慢查询分析是 MySQL 性能治理的入口。它要求把 SQL、执行计划、运行时间、扫描行数、锁等待、系统资源和业务流量放在同一条证据链上。
# 1. 学习定位
| 维度 | 内容 |
|---|---|
| 难度层级 | 排障实践 |
| 核心目标 | 先会用，再理解机制，最后能做工程取舍和故障分析 |
| 学习方法 | 带着业务场景看命令、SQL、数据结构、日志和运行时指标 |
# 2. 核心地图
慢查询与性能分析
├─ slow log
├─ digest
├─ pt-query-digest
├─ Performance Schema
├─ sys schema
├─ 锁等待
├─ IO 指标
└─ CPU 指标
# 3. 小章节深度讲解
下面把核心地图中的每个点拆开讲。每个小节都同时面向开发和运维：开发侧关注怎么设计、怎么写代码、怎么避免错误；运维侧关注怎么监控、怎么定位、怎么恢复。
# 3.1. slow log
# 是什么
slow log 是 MySQL 可靠性和复制链路中的关键日志或日志阶段。不同日志服务不同目标：崩溃恢复、逻辑复制、慢 SQL 分析、错误诊断或审计。
# 开发人员怎么用
开发人员要控制事务大小和写入频率，避免一次提交产生过大日志。涉及消息、缓存和外部系统时，要理解提交成功和外部可见之间的边界。
# 运维人员怎么看
运维人员要监控日志刷盘、磁盘空间、binlog 保留、复制 relay log、慢日志体积和错误日志。日志策略必须服务恢复目标，而不是只看默认配置。
# 常见风险
常见风险是日志占满磁盘导致实例不可写，或者误删 binlog 后无法做时间点恢复。
# 3.2. digest
# 是什么
digest 属于 MySQL 性能分析与优化证据。它帮助判断问题发生在 SQL 写法、优化器估算、索引路径、内存缓存、CPU、IO 还是锁等待。
# 开发人员怎么用
开发人员要在改 SQL 前保留基线：原 SQL、参数、执行计划、耗时、扫描行数和返回行数。没有基线，优化很容易变成猜测。
# 运维人员怎么看
运维人员要把慢日志、Performance Schema、sys schema、系统 IO/CPU 和应用 trace 对齐到同一时间线。性能问题很少只靠一个指标就能定案。
# 常见风险
常见风险是只看平均耗时或只看是否走索引，忽略统计信息失真、数据倾斜、缓存污染和高并发下的资源争用。
# 3.3. pt-query-digest
# 是什么
pt-query-digest 属于 MySQL 性能分析与优化证据。它帮助判断问题发生在 SQL 写法、优化器估算、索引路径、内存缓存、CPU、IO 还是锁等待。
# 开发人员怎么用
开发人员要在改 SQL 前保留基线：原 SQL、参数、执行计划、耗时、扫描行数和返回行数。没有基线，优化很容易变成猜测。
# 运维人员怎么看
运维人员要把慢日志、Performance Schema、sys schema、系统 IO/CPU 和应用 trace 对齐到同一时间线。性能问题很少只靠一个指标就能定案。
# 常见风险
常见风险是只看平均耗时或只看是否走索引，忽略统计信息失真、数据倾斜、缓存污染和高并发下的资源争用。
# 3.4. Performance Schema
# 是什么
Performance Schema 属于 MySQL 性能分析与优化证据。它帮助判断问题发生在 SQL 写法、优化器估算、索引路径、内存缓存、CPU、IO 还是锁等待。
# 开发人员怎么用
开发人员要在改 SQL 前保留基线：原 SQL、参数、执行计划、耗时、扫描行数和返回行数。没有基线，优化很容易变成猜测。
# 运维人员怎么看
运维人员要把慢日志、Performance Schema、sys schema、系统 IO/CPU 和应用 trace 对齐到同一时间线。性能问题很少只靠一个指标就能定案。
# 常见风险
常见风险是只看平均耗时或只看是否走索引，忽略统计信息失真、数据倾斜、缓存污染和高并发下的资源争用。
# 3.5. sys schema
# 是什么
sys schema 属于 MySQL 性能分析与优化证据。它帮助判断问题发生在 SQL 写法、优化器估算、索引路径、内存缓存、CPU、IO 还是锁等待。
# 开发人员怎么用
开发人员要在改 SQL 前保留基线：原 SQL、参数、执行计划、耗时、扫描行数和返回行数。没有基线，优化很容易变成猜测。
# 运维人员怎么看
运维人员要把慢日志、Performance Schema、sys schema、系统 IO/CPU 和应用 trace 对齐到同一时间线。性能问题很少只靠一个指标就能定案。
# 常见风险
常见风险是只看平均耗时或只看是否走索引，忽略统计信息失真、数据倾斜、缓存污染和高并发下的资源争用。
# 3.6. 锁等待
# 是什么
锁等待 属于 MySQL 并发控制。锁不是简单阻塞工具，而是数据库在多事务并发下保护一致性、范围约束和表结构安全的机制。
# 开发人员怎么用
开发人员要让更新条件命中索引，统一资源访问顺序，并把重试设计成幂等。涉及状态、库存、余额的写入，要用条件更新缩小锁范围。
# 运维人员怎么看
运维人员要从阻塞链分析：持锁事务、等待事务、锁类型、索引路径、事务年龄和 SQL 来源。必要时结合 Performance Schema 与 InnoDB status。
# 常见风险
常见风险是无索引更新或长事务遇到 DDL，行锁、间隙锁和 MDL 叠在一起，最后表现为整张表像被冻住。
# 3.7. IO 指标
# 是什么
IO 指标 属于 MySQL 性能分析与优化证据。它帮助判断问题发生在 SQL 写法、优化器估算、索引路径、内存缓存、CPU、IO 还是锁等待。
# 开发人员怎么用
开发人员要在改 SQL 前保留基线：原 SQL、参数、执行计划、耗时、扫描行数和返回行数。没有基线，优化很容易变成猜测。
# 运维人员怎么看
运维人员要把慢日志、Performance Schema、sys schema、系统 IO/CPU 和应用 trace 对齐到同一时间线。性能问题很少只靠一个指标就能定案。
# 常见风险
常见风险是只看平均耗时或只看是否走索引，忽略统计信息失真、数据倾斜、缓存污染和高并发下的资源争用。
# 3.8. CPU 指标
# 是什么
CPU 指标 属于 MySQL 性能分析与优化证据。它帮助判断问题发生在 SQL 写法、优化器估算、索引路径、内存缓存、CPU、IO 还是锁等待。
# 开发人员怎么用
开发人员要在改 SQL 前保留基线：原 SQL、参数、执行计划、耗时、扫描行数和返回行数。没有基线，优化很容易变成猜测。
# 运维人员怎么看
运维人员要把慢日志、Performance Schema、sys schema、系统 IO/CPU 和应用 trace 对齐到同一时间线。性能问题很少只靠一个指标就能定案。
# 常见风险
常见风险是只看平均耗时或只看是否走索引，忽略统计信息失真、数据倾斜、缓存污染和高并发下的资源争用。
# 3.9. 本篇学习实验
建议准备一个至少百万行级别的测试表，分别观察正常查询、缺失索引、错误索引、长事务、锁等待和慢查询日志。每次实验都记录 SQL、执行计划、耗时、扫描行数和 MySQL 状态变量变化。
开发侧实验重点是理解 SQL 与事务边界，运维侧实验重点是理解指标如何变化。真正掌握本篇内容，应该能从现象反推 SQL、索引、锁、日志或存储引擎问题。
# 4. 核心机制
- 慢查询日志记录超过阈值的 SQL，可用于发现高耗时和高频低效查询。
- Performance Schema 能记录等待事件、语句摘要、锁和事务等更细粒度信息。
- sys schema 对 Performance Schema 做了易读封装，适合快速定位热点表和热点语句。
- 慢查询不一定是 SQL 本身慢，锁等待、磁盘抖动、Buffer Pool miss 和复制延迟都可能放大耗时。
# 5. 工程实践
- 线上开启合理慢查询阈值，并定期聚合 Top SQL。
- 对慢 SQL 建立治理流程：发现、归因、优化、灰度、复测、归档。
- 分析时同时记录样本参数，避免只看模板 SQL。
- 把数据库指标接入告警，包括连接数、QPS、TPS、慢查询、锁等待、复制延迟和磁盘空间。
# 6. 常见坑
- 只优化耗时最长的一条 SQL，忽略高频中慢 SQL 的总成本。
- 慢日志阈值过高，等问题严重时才看见。
- 复制库慢查询被忽略，最终读链路雪崩。
- 没有优化前后对比，无法证明改动有效。
# 7. 专家视角
- 性能分析要讲证据，不讲玄学。每次优化都应该有基线和复测。
- 专家会按总耗时、平均耗时、扫描行数、返回行数和调用方进行多维排序。
- 慢查询治理是持续工程，不是故障时的一次性动作。
# 8. Tips 快问快答
Q：慢查询阈值设多少合适？
A：没有固定答案。核心 OLTP 可以较低，报表库可较高，关键是能发现问题且不淹没分析。
Q：慢日志里没有就一定没问题吗？
A：不一定。阈值、采样、锁等待记录方式和瞬时抖动都可能漏掉。
Q：高频 20ms SQL 要治理吗？
A：要看总成本。高频中慢 SQL 可能比单次 2s 的低频 SQL 更伤系统。
# 9. 阶段小结
慢查询与性能分析 的学习重点不是记住零散概念，而是把它放回真实系统：数据如何进入、如何存储、如何被查询、如何在并发下保持正确、如何在故障后恢复。掌握这些连接关系，才能从“会用”走向“能设计、能优化、能排障”。