首先通过慢查询日志定位低效SQL，结合EXPLAIN分析执行计划，检查索引使用情况，并监控数据库及系统状态，综合判断性能瓶颈。
分析 MySQL 查询性能瓶颈，关键在于定位慢查询、理解执行计划和优化资源使用。直接从实际问题出发，结合工具和指标能快速找到瓶颈所在。
启用慢查询日志定位低效语句
慢查询是性能问题的首要线索。开启慢查询日志，记录执行时间超过阈值的 SQL，便于后续分析。
- 在配置文件中设置：
slow_query_log = ON
long_query_time = 1（单位秒，按需调整）
slow_query_log_file = /var/log/mysql/slow.log - 运行过程中也可动态开启：
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1; - 配合 mysqldumpslow 或 pt-query-digest 分析日志，找出调用频繁或耗时最长的语句。
使用 EXPLAIN 分析执行计划
对可疑查询执行 EXPLAIN，查看 MySQL 如何执行该语句，重点关注是否走索引、扫描行数和连接方式。
- 在 SQL 前加上 EXPLAIN，例如：
EXPLAIN SELECT * FROM users WHERE age > 30; - 关注输出字段：
— type：连接类型，ALL 表示全表扫描，应尽量避免。
— key：实际使用的索引，为空则未命中。
— rows：预估扫描行数，越大越慢。
— Extra：出现 Using filesort 或 Using temporary 通常意味着额外开销。
检查索引设计与使用情况
缺失或低效索引是常见瓶颈。确保查询条件、排序和连接字段有合适索引。
- 为 WHERE、JOIN、ORDER BY 中常用字段建立索引，但避免过度索引影响写性能。
- 使用复合索引时注意最左前缀原则，例如索引 (a,b,c)，查询条件含 a 才能生效。
- 通过 SHOW INDEX FROM table_name; 查看现有索引结构。
- 利用 INFORMATION_SCHEMA.STATISTICS 表批量分析索引分布。
监控系统与数据库状态
结合实时状态判断资源瓶颈是 CPU、内存还是 I/O 导致查询变慢。
- 执行 SHOW STATUS LIKE 'Key_%'; 查看缓存命中率，Key_read_requests / Key_reads 越高越好。
- 使用 SHOW PROCESSLIST; 观察是否有大量查询处于 Locked 或 Sending data 状态。
- 监控 InnoDB 状态：SHOW ENGINE INNODB STATUS\G，可看到最近死锁、事务等待等信息。
- 操作系统层面使用 top、iotop、vmstat 判断是否存在资源争用。
基本上就这些。从日志入手，用 EXPLAIN 看执行路径，再结合索引和系统状态综合判断，大多数查询性能问题都能定位清楚。
