性能监控与调优速查 - MySQL 教程

讲解

调优的第一原则是「先观测，再动手」。SHOW GLOBAL STATUS 暴露几百个运行计数器，常用的一小把就够：Threads_connected（当前连接数，逼近 max_connections 就要告警）、Slow_queries（慢查询累计数，配合慢日志定位）、Questions/Queries（总查询量，除以 Uptime 得 QPS）、Innodb_buffer_pool_reads（物理读次数，相对逻辑读 Innodb_buffer_pool_read_requests 的比例就是缓存 miss 率）。SHOW PROCESSLIST 抓「当下正在执行什么」——线上突卡时先看它，谁在跑、跑了多久、什么状态一目了然。

观测之外还有现成的工具集：sys 库（8.0 自带）把 performance_schema 的原始数据包装成好读的视图，比如 schema_table_statistics 看哪张表最忙、statement_analysis 看哪类语句最耗时。调优的优先级要记牢：索引与 SQL 改写 > 表结构与范式 > 参数调整 > 硬件升级。绝大多数「数据库慢」是缺索引或烂 SQL，一个对的索引胜过十倍内存；参数里最值钱的是 innodb_buffer_pool_size，其余参数别盲目照抄网上的「优化模板」。

最后附一份常见报错速查：1045 认证失败（密码错或 host 不允许）、1046 没选默认库（USE 一下或写全库名）、1062 主键/唯一键冲突、1146 表不存在（多半连错库或拼错名）、1213 死锁（查应用的重试逻辑）、1267 排序规则不一致（统一字符集）、2002/2003 连不上（服务没起、端口或防火墙问题）。报错信息本身通常就指明了方向，完整读一遍再动手。

示例

日常巡检四连：连接数、慢查询数、总查询量、当前正在执行的会话：

SHOW GLOBAL STATUS LIKE 'Threads_connected';

SHOW GLOBAL STATUS LIKE 'Slow_queries';

SHOW GLOBAL STATUS LIKE 'Questions';

SHOW PROCESSLIST;

用 sys 库视图找最忙的表，并确认 buffer pool 的实际大小（字节换算成 MB）：

SELECT * FROM sys.schema_table_statistics LIMIT 3;

SELECT ROUND(@@GLOBAL.innodb_buffer_pool_size / 1024 / 1024) AS buffer_pool_mb;

演示「报错信息要看全」：触发一个除零警告，用 SHOW WARNINGS 查看完整信息——排查错误时这是标准动作：

SELECT 1 / 0 AS div_zero;

SHOW WARNINGS;

常见坑

没有监控就调参：凭感觉改 buffer pool、改连接数，改完没有对比数据，变好变坏全靠猜。先建观测（慢日志、STATUS 指标、sys 视图），再谈优化。
只调参数不改 SQL：全表扫描的 SQL 给再多内存也快不了。先看慢日志找最慢的十条，EXPLAIN 分析，该加索引加索引、该改写改写。
buffer pool 给过头：超过物理内存导致 swap，性能雪崩比默认值还惨。专用机 50%~70%，混部署要更保守。
看到报错就重启：重启掩盖问题不解决问题，1213 死锁、连接打满这类问题重启后还会复发。按报错码定位根因，修复后验证。

小结

调优靠观测：SHOW GLOBAL STATUS 看指标、SHOW PROCESSLIST 抓现行、sys 库视图找热点；优化优先级是索引与 SQL > 结构 > 参数 > 硬件；常见报错按码速查。26 章到此结束——从装库、设计、索引到备份、复制、调优，你已经见过 MySQL 管理与设计的全景，剩下的就是去真实环境里练。