MySQL慢查询优化：从基础到多表关联与高级技巧

咱说句不带脑子的实话哈——MySQL慢查询这玩意，是真能恶心人。有时候你页面转半天转不出来，服务直接卡死，日志一看，全是些慢得跟二舅磨豆腐似的SQL，真的气得想摔电脑。但骂归骂，还得撸起袖子一个一个给它收拾了；要不老板一天一催，你项目上不去，锅不还是你背？所以今天咱就来正儿八经地唠一唠这个破玩意该咋整，咋整得顺溜。

一、慢查询是啥？为啥慢得跟个大爷似的？

说白了就是你写的SQL慢得要命，MySQL自己也看不下去了，就给你记下来了。默认超3秒就算“慢”，慢日志文件就一顿记，你写的那些鬼畜SQL全都原形毕露。

怎么开这功能先说一下，别还没打开呢你就说“我咋没日志啊哥”：

show variables like '%slow_query_log%';
set global slow_query_log = 1;
set global long_query_time = 1;

**注意啊！**你这设置的只是当前会话，重启就没了，得写配置文件 my.cnf：

[mysqld]
slow_query_log = 1
slow_query_log_file = /var/lib/mysql/mysql-slow.log
long_query_time = 1

写完重启一下MySQL，不然等啥呢等天降优化神仙？

二、基础排查：别一上来就扯多表啥的，先看单表结构行不行？

别看不起单表问题哈，我跟你说，80%的慢查询都能在单表就掐死。

1. 没加索引，纯靠全表扫

你说你一张几百万数据的表，连个主键都不设，WHERE条件全靠扫描，MySQL不慢才怪咧；

select * from user where email = 'aaa@ddkk.com';

email没索引？那完了，MySQL只能一个一个看，跟找媳妇儿一样靠眼缘。

2. 索引用了，但用得贼差！

这就得讲讲执行计划了（慢点啊，别一看 explain 就眼花），一个type = ALL的计划就是告诉你：兄弟，这查询基本就是拉垮。

explain select * from user where year(birthday) = 1990;

为啥这玩意慢？因为你在字段上套了函数，索引压根用不上。你得这么写：

select * from user where birthday between '1990-01-01' and '1990-12-31';

这就舒服多了，MySQL一看条件能套上索引，嗖一下就给你查出来了。

三、多表JOIN卡成狗？那是你SQL写得像坨屎！

你一问优化就开始说“我这是多表联查，业务复杂没办法”，大哥，复杂归复杂，你得写明白吧！

1. 瞎JOIN，ON写错，直接爆炸

select * from order o join user u on o.user_id = u.id;

乍一看没问题，但你仔细瞅瞅——user表有几十万，order表也有几百万，一JOIN没过滤，查出来个几千万行那不是玩儿呢？

你得先筛选：

select * from order o 
join user u on o.user_id = u.id 
where o.create_time > now() - interval 1 day;

再不济也得 LIMIT 一下吧，查那么多干嘛，过年发客户？

2. LEFT JOIN 加WHERE，自己挖坑跳

select * from a left join b on a.id = b.a_id where b.name = '张三';

你这是 LEFT JOIN 伪装的 INNER JOIN 啊兄弟，干脆直接 inner join 得了，还不如实在点。

四、EXPLAIN 真不是摆设，光说慢不查EXPLAIN纯属耍流氓

咱实打实地讲，很多人都不爱看 explain，觉得看不懂。其实没那么玄乎，你只要盯住几个核心指标：

type：最好别是 ALL，越往上越好（range, ref, const那是宝贝）
rows：越少越好，越多说明MySQL得扫越多数据
Extra：出现“Using temporary”、“Using filesort”就得小心了，这俩是慢查询之王

举个栗子：

explain select * from user where name like '张%';

这还能用上索引，但你要是写成 like '%张%'，那完了，全表扫描起飞。

五、高级优化骚操作：没点实战经验你真玩不来！

1. 用覆盖索引（避免回表）

select id, name from user where name = '张三';

只查索引能覆盖的字段，MySQL就不会回表了，效率高得跟蹿稀似的。

2. 拆分页优化（大分页滚蛋）

你页数一大，LIMIT 100000, 20，MySQL根本不搭理你，这种用法就是死。

该咋整？用索引分页：

select * from user where id > 上一页最后一条id limit 20;

3. 慢日志定时分析脚本+pt-query-digest

这才是大哥该有的样子，定时拉慢日志分析出来，看哪些SQL最挫最该优化，一顿操作猛如虎，最后数据库省一半资源！

总结：优化是个细活儿，甭想着一步到位，甭嫌啰嗦！

唉，这东西真不是一蹴而就的，慢SQL它就像家里马桶堵了一样，你得一截一截往下通，不能指望一锤子砸通。

从基础的建索引、字段设计、到中间的执行计划分析、再到最后的分页优化、覆盖索引、高阶手法啥的，都得一个一个来；别浮躁，别想靠AI提示一劳永逸，优化这种事儿——得是你真TM肝过、熬过夜、骂过MySQL你才知道那味儿。

行了兄弟们，就到这吧；有啥坑你踩了的，评论区甩出来咱一块喷、顺便也整整那些写得比屎还难看的SQL。

MySQL慢查询优化全攻略：从入门建索引到多表联查实战拆解