大家好，我是小米，一個(gè)31歲、天天被面試題支配的社畜程序員。最近后臺(tái)有小伙伴跟我說(shuō)：“小米，你能不能聊聊 WHERE子句優(yōu)化？上次面試官問我，我一緊張就只說(shuō)了‘建索引’，結(jié)果當(dāng)場(chǎng)涼透了。”

哈哈，這個(gè)問題我太有感觸了！因?yàn)槲耶?dāng)年第一次參加社招面試的時(shí)候，面試官問的第一個(gè)SQL問題就是：

“如果SQL語(yǔ)句的WHERE子句效率很低，你會(huì)怎么優(yōu)化？”

我當(dāng)時(shí)也是秒答：“建索引??！”結(jié)果面試官笑了笑，說(shuō)：“嗯，光會(huì)說(shuō)這個(gè)，說(shuō)明你只停留在表面。”那一刻，我才意識(shí)到：優(yōu)化WHERE子句遠(yuǎn)遠(yuǎn)不只是建個(gè)索引那么簡(jiǎn)單。

今天這篇文章，就帶大家從面試題的角度，系統(tǒng)聊聊 如何優(yōu)化WHERE子句，不僅告訴你該怎么答題，還會(huì)順帶幫你理清思路，以后再遇到類似問題，你能胸有成竹地侃侃而談。

解題方法：面試官想聽什么？

面試官拋出這個(gè)問題，本質(zhì)上是考察你兩點(diǎn)：

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

你得知道，SQL變慢的根源在哪。是不是走了全表掃描？是不是索引沒用上？是不是數(shù)據(jù)量爆炸？

2、是否有系統(tǒng)化的優(yōu)化思路

面試官要聽的不是你一上來(lái)就說(shuō)“加索引”，而是希望你能有邏輯：

• 先定位SQL語(yǔ)句是否低效；
• 再分析低效的原因；
• 最后給出逐步優(yōu)化的方案。

所以，正確的解題框架應(yīng)該是：

第一步：定位低效SQL

• 打開慢查詢?nèi)罩荆╯low query log），確認(rèn)問題SQL。
• 用 EXPLAIN 查看執(zhí)行計(jì)劃，看是否走了索引、是否出現(xiàn) ALL（全表掃描）。

第二步：分析原因

• 索引缺失？
• WHERE子句里用了不合適的寫法？
• 數(shù)據(jù)訪問量過(guò)大？
• 還是語(yǔ)句本身過(guò)于復(fù)雜？

第三步：逐項(xiàng)排查，提出優(yōu)化方法

• 索引問題 → 建合適的索引。
• 語(yǔ)句寫法問題 → 調(diào)整寫法，避免函數(shù)/表達(dá)式。
• 數(shù)據(jù)訪問問題 → 限制列數(shù)、分頁(yè)優(yōu)化。
• 特定情況 → 用全文索引、分庫(kù)分表、緩存。

這樣答題，面試官會(huì)覺得你有方法論，而不是只會(huì)背八股文。

接下來(lái)我們進(jìn)入實(shí)戰(zhàn)。WHERE子句為什么會(huì)慢？我整理了10個(gè)常見場(chǎng)景，面試時(shí)直接說(shuō)出來(lái)，絕對(duì)加分。

缺少索引或索引沒用上

問題：查詢條件的列沒有索引，或者索引被寫法“廢掉了”。

優(yōu)化：在 WHERE、ORDER BY、GROUP BY 常用列上建合適的索引。

舉例：

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

WHERE子句對(duì)字段進(jìn)行 NULL 判斷

問題：

這種寫法，索引基本無(wú)效。

優(yōu)化：用默認(rèn)值替代 NULL，或者在設(shè)計(jì)表時(shí)避免 NULL。

使用 != 或 <>

問題：

會(huì)導(dǎo)致引擎放棄索引，轉(zhuǎn)為全表掃描。

優(yōu)化：用范圍查詢代替，比如：

使用 OR 連接條件

問題：

大概率會(huì)導(dǎo)致全表掃描。

優(yōu)化：用 UNION ALL 拆開兩條SQL，再加索引。

濫用 IN 和 NOT IN

問題：

范圍太大時(shí)會(huì)拖慢查詢。

優(yōu)化：

• 用 EXISTS 替代。
• 或者把大范圍數(shù)據(jù)拆成小批次。

模糊查詢 %xxx%

問題：

前置 %，索引直接失效。

優(yōu)化：

• 改成 name like '小米%'；
• 用全文索引（FULLTEXT）。

WHERE子句里用參數(shù)

問題：

參數(shù)在編譯時(shí)未知，優(yōu)化器沒法用索引。

優(yōu)化：用存儲(chǔ)過(guò)程或拼接SQL。

對(duì)字段做表達(dá)式操作

問題：

amount 上的索引會(huì)失效。

優(yōu)化：改寫成：

對(duì)字段做函數(shù)操作

問題：

同樣廢掉索引。

優(yōu)化：改寫成：

在 = 左邊使用函數(shù)或運(yùn)算

問題：

索引無(wú)效。

優(yōu)化：改成：

WHERE子句優(yōu)化思路：一個(gè)小故事

給大家講個(gè)真實(shí)的小插曲。

之前我們項(xiàng)目里有個(gè)報(bào)表查詢，SQL長(zhǎng)這樣：

一跑就卡，幾十萬(wàn)行數(shù)據(jù)，跑了30秒。

后來(lái)我們排查發(fā)現(xiàn)：

1. year(join_date) 把索引廢掉了。
2. order by salary desc 沒索引，導(dǎo)致額外排序。

于是我們做了兩步優(yōu)化：

• 改寫SQL，把函數(shù)去掉：

• 給 salary 建索引。

結(jié)果呢？SQL從30秒縮短到不到1秒！老板看了直接夸：“小米，SQL優(yōu)化小能手！”

這件事給我一個(gè)啟發(fā)：SQL優(yōu)化不是玄學(xué)，而是細(xì)節(jié)的積累。

總結(jié)：答題萬(wàn)能公式

面試時(shí)如果被問到“如何優(yōu)化WHERE子句”，你完全可以用下面這個(gè)萬(wàn)能公式來(lái)回答：

1. 先定位問題：開啟慢查詢?nèi)罩荆?EXPLAIN 看執(zhí)行計(jì)劃。
2. 從索引入手：WHERE、ORDER BY、GROUP BY 列上建索引。
3. 排查寫法問題：避免 !=、<>、OR、IN、NOT IN、前置 %、函數(shù)/表達(dá)式操作等。
4. 優(yōu)化特定情況：用全文索引、分批查詢、改寫SQL。
5. 逐層遞進(jìn)：從索引 → 數(shù)據(jù)訪問 → 語(yǔ)句寫法 → 特殊優(yōu)化。

這樣一套邏輯說(shuō)下來(lái)，面試官絕對(duì)會(huì)覺得：哇，這小伙子有經(jīng)驗(yàn)、有思路，不是只會(huì)背書。

最后的話

寫到這里，我想說(shuō)，SQL優(yōu)化其實(shí)是一種“武功修煉”。一開始你可能只會(huì)用“索引”這把大刀亂砍，但隨著經(jīng)驗(yàn)積累，你會(huì)學(xué)會(huì)更精細(xì)的招式，比如改寫SQL、利用執(zhí)行計(jì)劃、選擇合適的存儲(chǔ)結(jié)構(gòu)。

所以，下次面試官再問你“如何優(yōu)化WHERE子句”，別慌。微微一笑，然后用今天學(xué)到的這套邏輯回答，保證能讓面試官眼前一亮！

END

那么，小伙伴們，你們?cè)诠ぷ髦杏袥]有遇到過(guò) WHERE子句優(yōu)化的坑？比如寫了個(gè)模糊查詢結(jié)果全表掃描？歡迎在評(píng)論區(qū)分享你的故事，我們一起探討！

我是小米，一個(gè)喜歡分享技術(shù)的31歲程序員。如果你喜歡我的文章，歡迎關(guān)注我的微信公眾號(hào)“軟件求生”，獲取更多技術(shù)干貨！

到此這篇關(guān)于MySQL數(shù)據(jù)庫(kù)社招必考題：索引如何優(yōu)化WHERE子句？的文章就介紹到這了,更多相關(guān)Mysql數(shù)據(jù)庫(kù)社招之WHERE優(yōu)化內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論