MySQL查询优化需四步：慢查询定位→执行计划解读→索引与语句优化→系统资源验证；先启用慢日志分析瓶颈，再用EXPLAIN查看type/key/rows/Extra，遵循最左前缀建索引，避免函数操作字段，最后检查缓冲池命中率。

MySQL 查询执行时间长，核心要从 慢查询定位 → 执行计划解读 → 索引与语句优化 → 系统资源验证 四步入手，不能只看“花了多久”，得知道“卡在哪”。

开启并分析慢查询日志

这是发现性能问题的第一手线索。默认慢查询日志是关闭的，需手动启用：

• 在 my.cnf 中添加：
  slow_query_log = ON
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 1（单位秒，建议设为 0.5～1，便于捕获真实瓶颈）
• 重启 MySQL 或动态启用：
  SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1;
• 用 mysqldumpslow 工具快速汇总（例如 top 10 最慢查询）：
  mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log

用 EXPLAIN 看懂执行计划

对慢查询加 EXPLAIN 前缀，重点观察以下几列：

• type：值越靠前性能越好（system > const > eq_ref > ref > range > index > ALL）。出现 ALL 表示全表扫描，大概率缺索引
• key：实际使用的索引名。为 NULL 说明没走索引
• rows：预估扫描行数。远大于结果集行数（如 SELECT 返回 10 行，但 rows=50000），说明过滤效率低
• Extra：警惕 Using filesort（排序未走索引）、Using temporary（用了临时表）、Using join buffer（连接缓存回退到内存/磁盘）

检查索引有效性与 SQL 写法

很多慢查表面是语句问题，根子在索引没建对或被隐式失效：

• 复合索引要遵循 最左前缀原则：WHERE 条件中跳过左边字段，右边字段就无法使用索引（如索引 (a,b,c)，WHERE b=2 AND c=3 不走索引）
• 避免在 WHERE 字段上做函数或运算：
  ❌ WHERE YEAR(create_time) = 2025 → 改为 ✅ WHERE create_time >= '2025-01-01' AND create_time
• 少用 SELECT *，尤其大表关联时；明确需要字段，减少网络传输和临时表开销
• 分页深翻慎用 LIMIT 10000,20：改用游标方式（如记录上一页最大 ID）或延迟关联

结合系统指标交叉验证

SQL 本身没问题，也可能是资源瓶颈拖慢执行：

• 查当前活跃会话与锁等待：
  SHOW PROCESSLIST;
SELECT * FROM information_schema.INNODB_TRX;
SELECT * FROM information_schema.INNODB_LOCK_WAITS;
• 观察 InnoDB 状态关键指标：
  SHOW ENGINE INNODB STATUS\G → 关注 ROW OPERATIONS、SEMAPHORES、TRANSACTIONS 部分
• 确认缓冲池命中率（理想 > 99%）：
  (Innodb_buffer_pool_read_requests - Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests