MySQL 社招必考题: 如何优化WHERE子句?

发布日期：2025-10-08 11:45    点击次数：110

大家好，我是小米，一个31岁、天天被面试题支配的社畜程序员。最近后台有小伙伴跟我说：“小米，你能不能聊聊WHERE子句优化？上次面试官问我，我一紧张就只说了‘建索引’，结果当场凉透了。”

哈哈，这个问题我太有感触了！因为我当年第一次参加社招面试的时候，面试官问的第一个SQL问题就是：

“如果SQL语句的WHERE子句效率很低，你会怎么优化？”

我当时也是秒答：“建索引啊！”结果面试官笑了笑，说：“嗯，光会说这个，说明你只停留在表面。”那一刻，我才意识到：优化WHERE子句远远不只是建个索引那么简单。

今天这篇文章，就带大家从面试题的角度，系统聊聊如何优化WHERE子句，不仅告诉你该怎么答题，还会顺带帮你理清思路，以后再遇到类似问题，你能胸有成竹地侃侃而谈。

解题方法：面试官想听什么？

面试官抛出这个问题，本质上是考察你两点：

1、是否具备定位低效SQL的能力

你得知道，SQL变慢的根源在哪。是不是走了全表扫描？是不是索引没用上？是不是数据量爆炸？

2、是否有系统化的优化思路

面试官要听的不是你一上来就说“加索引”，而是希望你能有逻辑：

先定位SQL语句是否低效；

再分析低效的原因；

最后给出逐步优化的方案。

所以，正确的解题框架应该是：

第一步：定位低效SQL

打开慢查询日志（slow query log），确认问题SQL。

用 EXPLAIN 查看执行计划，看是否走了索引、是否出现 ALL（全表扫描）。

第二步：分析原因

索引缺失？

WHERE子句里用了不合适的写法？

数据访问量过大？

还是语句本身过于复杂？

第三步：逐项排查，提出优化方法

索引问题 → 建合适的索引。

语句写法问题 → 调整写法，避免函数/表达式。

数据访问问题 → 限制列数、分页优化。

特定情况 → 用全文索引、分库分表、缓存。

这样答题，面试官会觉得你有方法论，而不是只会背八股文。

接下来我们进入实战。WHERE子句为什么会慢？我整理了10个常见场景，面试时直接说出来，绝对加分。

缺少索引或索引没用上

问题：查询条件的列没有索引，或者索引被写法“废掉了”。

优化：在 WHERE、ORDER BY、GROUP BY 常用列上建合适的索引。

举例：

在 age 上建索引，就能避免全表扫描。

WHERE子句对字段进行 NULL 判断

问题：

这种写法，索引基本无效。

优化：用默认值替代 NULL，或者在设计表时避免 NULL。

使用 != 或

问题：

会导致引擎放弃索引，转为全表扫描。

优化：用范围查询代替，比如：

使用 OR 连接条件

问题：

大概率会导致全表扫描。

优化：用 UNION ALL 拆开两条SQL，再加索引。

滥用 IN 和 NOT IN

问题：

范围太大时会拖慢查询。

优化：

用 EXISTS 替代。

或者把大范围数据拆成小批次。

模糊查询 %xxx%

问题：

前置 %，索引直接失效。

优化：

改成 name like '小米%'；

用全文索引（FULLTEXT）。

WHERE子句里用参数

问题：

参数在编译时未知，优化器没法用索引。

优化：用存储过程或拼接SQL。

对字段做表达式操作

问题：

amount 上的索引会失效。

优化：改写成：

对字段做函数操作

问题：

同样废掉索引。

优化：改写成：

在 = 左边使用函数或运算

问题：

索引无效。

优化：改成：

WHERE子句优化思路：一个小故事

给大家讲个真实的小插曲。

之前我们项目里有个报表查询，SQL长这样：

一跑就卡，几十万行数据，跑了30秒。

后来我们排查发现：

year(join_date) 把索引废掉了。

order by salary desc 没索引，导致额外排序。

于是我们做了两步优化：

改写SQL，把函数去掉：

给 salary 建索引。

结果呢？SQL从30秒缩短到不到1秒！老板看了直接夸：“小米，SQL优化小能手！”

这件事给我一个启发：SQL优化不是玄学，而是细节的积累。

总结：答题万能公式

面试时如果被问到“如何优化WHERE子句”，你完全可以用下面这个万能公式来回答：

先定位问题：开启慢查询日志，用 EXPLAIN 看执行计划。

从索引入手：WHERE、ORDER BY、GROUP BY 列上建索引。

排查写法问题：避免 !=、、OR、IN、NOT IN、前置 %、函数/表达式操作等。

优化特定情况：用全文索引、分批查询、改写SQL。

逐层递进：从索引 → 数据访问 → 语句写法 → 特殊优化。

这样一套逻辑说下来，面试官绝对会觉得：哇，这小伙子有经验、有思路，不是只会背书。

最后的话

写到这里，我想说，SQL优化其实是一种“武功修炼”。一开始你可能只会用“索引”这把大刀乱砍，但随着经验积累，你会学会更精细的招式，比如改写SQL、利用执行计划、选择合适的存储结构。

所以，下次面试官再问你“如何优化WHERE子句”，别慌。微微一笑，然后用今天学到的这套逻辑回答，保证能让面试官眼前一亮！

END

那么，小伙伴们，你们在工作中有没有遇到过WHERE子句优化的坑？比如写了个模糊查询结果全表扫描？欢迎在评论区分享你的故事，我们一起探讨！