MySQL 慢查询：从开到优化的完整链路

网站"偶尔卡一下"，八成是数据库某条 SQL 拖的。慢查询日志就是抓它的网，但很多人开了却从不看，或者开了之后被日志本身拖慢。

第一步：确认是否已开启

SHOW VARIABLES LIKE 'slow_query_log';
SHOW VARIABLES LIKE 'long_query_time';

如果 slow_query_log 是 OFF，在配置文件里打开。宝塔的路径一般在 /etc/my.cnf 或 /www/server/mysql/etc/my.cnf：

slow_query_log = 1
slow_query_log_file = /www/server/data/mysql-slow.log
long_query_time = 2
log_queries_not_using_indexes = 1

long_query_time 默认 10 秒，对现在的网站太宽松了，先设 2 秒。等摸清底细后再降到 1 秒甚至 0.5 秒。

第二步：别让日志失控

log_queries_not_using_indexes 打开后，所有没走索引的查询都会记下来。如果站点本身索引建得差，这个日志一天能涨几百兆。建议：先开一周看看，摸清问题后就关掉，或者加 log_throttle_queries_not_using_indexes = 10 限制每分钟记录条数。

第三步：读日志

慢查询日志的格式不复杂，重点看三行：

# Query_time: 3.214  Lock_time: 0.000  Rows_sent: 1  Rows_examined: 120000
SET timestamp=1794016800;
SELECT * FROM zbp_post WHERE log_Title LIKE '%关键词%';

Rows_examined 是核心指标：扫了 12 万行只返回 1 行，说明索引完全没用上。这种情况下加索引的效果立竿见影。

第四步：定位与优化

把可疑 SQL 拿去 EXPLAIN：

EXPLAIN SELECT ...;

关注 type 和 key。type=ALL 是全表扫描，key=NULL 说明没走索引。常见优化手段：

• 给 WHERE、ORDER BY、GROUP BY 里高频出现的列建索引
• 联合索引注意最左前缀，别把选择性低的列放最前
• LIKE '%xxx%' 无法用索引，考虑换全文检索或者加前缀匹配
• 大表分页用"游标"方式，别用大偏移量的 LIMIT

注意别过度索引

索引不是越多越好。每个索引都会拖慢写入、占磁盘。一张表三四个索引已经不少了，加之前先想想这个查询到底有多高频。

最后一个经验：优化前先备份，改索引在生产库上是有风险的。可以先在从库或者测试库验证效果，再动主库。