1. 索引到底是什么一次磁盤I/O引發(fā)的思考1.1 為什么沒有索引會慢先從一個我實際處理的真實問題說起。去年給一個電商后臺做性能排查訂單表有幾十萬行數(shù)據(jù)列表頁每次查詢都要花兩秒多。加了索引之后同樣的SQL查詢時間直接降到了幾十毫秒。這里面起關鍵作用的就是索引。如果一張表沒有索引MySQL要找到某一行數(shù)據(jù)只能走全表掃描。所謂全表掃描就是從表的第一行開始一行一行地讀進內存然后逐條匹配WHERE條件。表里有100萬行數(shù)據(jù)最壞情況下要讀100萬行表里有1000萬行就要讀1000萬行。這個成本是線性增長的數(shù)據(jù)量翻一倍查詢時間也差不多翻一倍。這里有個很核心的概念叫磁盤I/O。InnoDB存儲引擎的數(shù)據(jù)不是按行存儲的而是按頁存儲的一個頁默認是16KB。MySQL做全表掃描時需要把一個個數(shù)據(jù)頁從磁盤加載到內存。磁盤I/O的速度和內存相比慢了大概三到四個數(shù)量級。也就是說一次隨機磁盤讀可能耗時10毫秒左右而一次內存訪問只要幾十納秒。所以全表掃描慢的本質不是CPU不夠快而是I/O次數(shù)太多了。索引解決的就是這個問題它利用一種高效的數(shù)據(jù)結構讓你不需要掃描所有數(shù)據(jù)頁只需要讀幾個關鍵節(jié)點就能快速定位到目標記錄的位置。類比來說沒有索引就像在一本沒有目錄的書里找某個關鍵詞必須一頁一頁翻有索引就像先翻目錄直接跳到對應頁碼效率完全不在一個量級。1.2 B樹為什么能成為索引的事實標準MySQL InnoDB引擎的索引默認使用B樹結構。為什么不是二叉樹不是哈希表偏偏是B樹這要從幾個角度去理解。先說二叉搜索樹。它的問題很明顯數(shù)據(jù)如果按順序插入二叉樹會退化成一條鏈表查找復雜度變成O(n)。即便用紅黑樹這種自平衡二叉查找樹每個節(jié)點最多只能有兩個子節(jié)點數(shù)據(jù)量大時樹的高度會非常高。樹的高度決定了查詢時需要經(jīng)歷的磁盤I/O次數(shù)高度為10就要讀10次磁盤頁這顯然不可接受。再說B樹。B樹是一種多路平衡查找樹一個節(jié)點能存儲多個鍵值和多個子節(jié)點指針所以樹能做得更矮。B樹中每個節(jié)點都可以存放數(shù)據(jù)這意味著同樣大小的節(jié)點里存放的鍵數(shù)量變少節(jié)點的分支數(shù)也會變少一定程度上影響了樹的矮化效果。B樹在B樹的基礎上做了兩個關鍵改動改動一非葉子節(jié)點只存儲索引鍵值不存儲實際數(shù)據(jù)。這樣每個數(shù)據(jù)頁能容納的鍵數(shù)量大大增加。拿16KB的頁來算如果一個鍵占8字節(jié)加上指針占6字節(jié)那一個頁大約就能容納1200個鍵。高度為2的B樹大概能存1200個葉子節(jié)點每個葉子節(jié)點按1KB算能存約16行數(shù)據(jù)那總共就是200萬行左右高度為3時就能存二十多億行。改動二所有葉子節(jié)點通過雙向鏈表相連并且葉子節(jié)點本身按鍵值從小到大排序。這意味著B樹天然支持高效的順序訪問和范圍查詢。你要查某個范圍內的所有記錄只需要找到范圍起點然后沿著葉子節(jié)點的鏈表一路向后遍歷即可不需要像B樹那樣在父子節(jié)點間反復回溯。我經(jīng)常用一個類比來解釋B樹B樹的非葉子節(jié)點就像書的目錄只告訴你章節(jié)在哪一頁葉子節(jié)點才是正文內容本身。目錄做得再大也不會影響正文的查找反而因為目錄更精簡翻目錄的速度更快。1.3 InnoDB中索引和數(shù)據(jù)是怎么存在一起的InnoDB的索引和數(shù)據(jù)其實沒有辦法完全分開討論因為它是按照聚簇索引clustered index來組織數(shù)據(jù)的。每張InnoDB表都必須有一個聚簇索引這個聚簇索引的葉子節(jié)點存儲的是整行完整記錄索引的順序決定了表數(shù)據(jù)物理存儲的順序。默認情況下聚簇索引是按照主鍵來建的。如果你建表時沒有定義主鍵InnoDB會找第一個非空的唯一索引作為聚簇索引如果也沒有唯一索引它會在后臺隱式生成一個6字節(jié)的ROWID作為聚簇索引鍵。除了聚簇索引其他索引統(tǒng)稱為二級索引secondary index或輔助索引。二級索引的葉子節(jié)點存儲的不是完整行記錄而是索引列的值加上主鍵值。這意味著如果通過二級索引查找數(shù)據(jù)通常需要拿到主鍵值之后再到聚簇索引中查一次完整行記錄這個過程就叫回表。這里有一個非常實際的設計含義二級索引的大小很大程度上取決于主鍵的大小。主鍵越長每個二級索引的葉子節(jié)點能容納的記錄數(shù)就越少索引占用的磁盤空間就越大回表時查聚簇索引的效率也會受影響。所以在InnoDB表里選擇主鍵不是一個可以隨便對待的問題后面我會專門用一章來講主鍵該怎么選。2. 常見索引分類與選型2.1 普通索引、唯一索引、主鍵索引到底怎么選MySQL里的索引從功能上劃分主要有這么幾種。普通索引INDEX是最基礎的索引它沒有任何限制只負責加速查詢。唯一索引UNIQUE INDEX在普通索引的基礎上增加了唯一性約束索引列的值不能重復允許為NULL但NULL可以出現(xiàn)多次。主鍵索引PRIMARY KEY是特殊的唯一索引它不能為NULL而且在一張表里最多只能有一個。用一句話來記區(qū)別普通索引只要你需要提速就可以建唯一索引還要保證業(yè)務上不允許重復主鍵索引不僅要保證唯一還要承擔聚簇索引組織的責任。實際工作中我經(jīng)常遇到有人問既然唯一索引和主鍵索引都有唯一約束為什么不能全部用唯一索引當主鍵因為主鍵索引是聚簇索引的入口它直接決定了數(shù)據(jù)頁的物理排布而唯一索引只是在普通二級索引上加了約束兩者在存儲層面承擔的角色完全不同。選型時我的建議是業(yè)務查詢的核心篩選字段優(yōu)先考慮普通索引或聯(lián)合索引需要保證業(yè)務唯一性的字段用唯一索引主鍵盡量用與業(yè)務無關的、單值的、有序遞增的字段同一張表不要建太多索引否則寫入時要維護所有索引樹寫入速度會明顯變慢。2.2 聯(lián)合索引的最左前綴原則是怎么回事聯(lián)合索引也叫復合索引是指同時給多個列建立一個索引比如INDEX idx_user_status (user_id, status)。很多人以為只要建了聯(lián)合索引查詢里帶任何一列都能用上索引其實這是個誤區(qū)。聯(lián)合索引的核心規(guī)則是最左前綴原則。這個原則的意思是聯(lián)合索引的生效順序是從左往右查詢條件中必須包含最左邊的列索引才會被使用跳過了左邊的列右邊的列就無法利用索引。舉個具體例子。假設有一個聯(lián)合索引(a, b, c)WHERE a 1能用索引WHERE a 1 AND b 2能完整用上索引WHERE b 2 AND a 1同樣能完整用上索引因為MySQL優(yōu)化器會做條件下推和重排把查詢條件調整成a 1 AND b 2的順序WHERE a 1 AND c 3只能用到索引中的a列c列無法通過索引定位因為中間缺了bWHERE b 2完全用不上這個聯(lián)合索引。為什么必須有這個限制因為B樹是按索引鍵順序存儲的(a,b,c)這個聯(lián)合索引先按a排序a相同再按b排序b相同再按c排序。索引順序本質上是一個級聯(lián)排序邏輯缺少前邊的排序鍵后邊的鍵值在樹中根本不是一個連續(xù)區(qū)間自然無法快速定位。最左前綴原則還影響排序。比如SELECT * FROM t ORDER BY a可以用索引ORDER BY a, b也可以用但是ORDER BY b, c用不了。理解了B樹的存儲順序這個結論就不需要死記了。2.3 哪些場景適合建索引哪些堅決不適合這些年做過的慢查詢優(yōu)化里我把適合建索引的場景歸納為四類第一類出現(xiàn)在WHERE條件中、頻繁作為篩選依據(jù)的列。這類列是索引最容易發(fā)揮價值的地方。第二類經(jīng)常用于ORDER BY或GROUP BY的列。索引本身就是有序的如果查詢結果可以利用索引順序直接輸出MySQL就可以避免額外的排序操作省掉filesort。第三類多表關聯(lián)查詢中的關聯(lián)字段。比如訂單表和用戶表通過user_id關聯(lián)那user_id就應該有索引否則關聯(lián)時要用嵌套循環(huán)反復掃表代價極高。第四類需要保證唯一性的列如手機號、身份證號等可以用唯一索引既能加速查詢又能約束數(shù)據(jù)。那哪些場景不適合建索引我歸納出了四種第一種數(shù)據(jù)量太小的表。幾百行甚至幾千行的數(shù)據(jù)MySQL直接全表掃描代價不過幾次I/O建索引反而要額外維護索引結構性能上沒有收益還占磁盤空間。第二種更新頻率特別高的列。寫入一條記錄時MySQL不僅要更新數(shù)據(jù)頁還要同步維護這張表上每一個相關索引的B樹。插入、更新、刪除越頻繁索引維護成本越高可能直接拖垮寫入性能。第三種區(qū)分度太低的列。比如性別字段只有“男、女”兩個取值再往下查也就是兩種可能索引的選擇性太低。用這種列建索引每一層樹節(jié)點差不多都會命中大部分頁最后優(yōu)化器往往選擇全表掃描。第四種參與了函數(shù)運算或表達式運算的列。如果查詢時總要寫WHERE DATE(create_time) 2024-01-01這種寫法索引列被函數(shù)包裹后原來的B樹順序就失效了建了也大概率用不上。3. 索引失效的八個經(jīng)典場景與原理3.1 索引失效場景清單我在面試候選人時發(fā)現(xiàn)很多人能背出“索引失效有哪幾種情況”這個題但一旦問“為什么”就答不上來。這里我把自己日常開發(fā)和排查中總結的八個經(jīng)典失效場景整理成一張清單每個場景都配上原理說明。場景SQL示例失效原理對索引列使用函數(shù)WHERE LEFT(name, 3) abc函數(shù)改變了索引列的值B樹的鍵順序失效隱式類型轉換WHERE phone 13800138000phone是字符串類型MySQL會將字符串轉數(shù)字后再比較模糊匹配以通配符開頭WHERE name LIKE %張%無法利用B樹的有序性確定起始位置OR條件中存在非索引列WHERE age 18 OR status 1無法把索引列條件與普通列條件合并成一次索引掃描聯(lián)合索引不滿足最左前綴WHERE b 2 AND c 3缺少第一列的排序錨點聯(lián)合索引范圍查詢后的列WHERE a 1 AND b 2范圍查詢導致后續(xù)列區(qū)間不連續(xù)對索引列做計算WHERE age 10 30索引列參與表達式計算原鍵值順序失效優(yōu)化器選擇全表掃描小表或統(tǒng)計信息嚴重失真的情況優(yōu)化器基于代價估算認為全表掃描成本更低第一類對索引列使用函數(shù)是最常見也是最隱蔽的問題。你可能會想WHERE name LIKE 張%能用索引那WHERE LEFT(name, 1) 張為什么就不能原因很簡單索引的鍵值是原始列值不是經(jīng)過LEFT函數(shù)計算后的結果。B樹里存儲的是“張三”“李四”這種原始字符串函數(shù)計算后的結果和原始值之間沒有直接的順序映射關系MySQL只能掃完所有索引值再計算索引自然失效。第四類OR條件的失效我要多說一句。WHERE age 18 OR status 1如果只有age上有索引MySQL無法只走索引找到所有age18的記錄再附加status1的記錄因為OR要求兩個條件滿足其一兩個分支的集合需要合并而status沒有索引可以做快速定位最終就退化成全表掃描。解決辦法是給status也建索引或者改寫為UNION ALL。3.2 隱式類型轉換和范圍查詢的坑隱式類型轉換這個坑我在生產(chǎn)環(huán)境里踩過一次印象非常深刻。有一張用戶表手機號字段用的VARCHAR類型但查詢代碼里把手機號當成數(shù)字傳了進去寫成WHERE phone 13800138000。結果索引完全失效全表掃描每次查詢耗時好幾秒。為什么字符串列和數(shù)字比較會失效因為MySQL有一個隱式轉換規(guī)則當字符串列和數(shù)字值比較時它會把字符串列的值轉換為數(shù)字再比較。這么一轉換相當于對索引列套了一層CAST函數(shù)鍵值的順序自然就亂了。后來我把查詢改成WHERE phone 13800138000耗時從秒級降到毫秒級。再看范圍查詢。有一個聯(lián)合索引(a, b)執(zhí)行WHERE a 1 AND b 2從最左前綴原則來看a可以用索引定位但b能不能用取決于a的條件是什么。當a是等值條件時b還能保持有序當a是范圍條件時每個滿足a條件的分支里b的順序是全局不一定的無法直接通過索引繼續(xù)精確定位b2所以b列就失效了。這是聯(lián)合索引設計中非常重要的一個權衡點到底把等值條件的列放前面還是把范圍條件的列放前面要看實際業(yè)務里高頻查詢是哪種形態(tài)。3.3 優(yōu)化器為什么“不聽話”有時候你明明建了索引SQL里也沒有函數(shù)、沒有類型轉換、符合最左前綴但EXPLAIN一看還是全表掃描。這時候別急著懷疑人生先想想優(yōu)化器。MySQL的優(yōu)化器是基于代價模型來選擇執(zhí)行計劃的。它估算全表掃描的I/O次數(shù)、CPU消耗、內存排序開銷等等最后算出總代價。如果它認為走索引的代價比全表掃描高就會放棄索引。典型場景是表數(shù)據(jù)量很小或者查詢條件會命中表中很大比例的數(shù)據(jù)比如區(qū)分度很低的字段。還有一種是統(tǒng)計信息失真。InnoDB通過隨機采樣來估算索引的區(qū)分度如果表長時間沒有執(zhí)行ANALYZE TABLE統(tǒng)計信息可能已經(jīng)過時優(yōu)化器會基于錯誤的數(shù)據(jù)做出判斷。這種情況的排查方法是先執(zhí)行ANALYZE TABLE 表名;更新統(tǒng)計信息再重新EXPLAIN一次。另外還要注意SELECT *對優(yōu)化器決策的影響。如果你查的是SELECT *而二級索引里沒有全部列MySQL必須回表讀取完整行記錄。當回表比例很高時它的代價還不如全表掃描低優(yōu)化器就會放棄二級索引。這也引出了一個優(yōu)化方向盡量用覆蓋索引來減少回表后面我會詳細講。4. 主鍵設計與聚簇索引的存儲細節(jié)4.1 自增主鍵和UUID主鍵差的不是一點半點主鍵的選擇直接影響聚簇索引的物理結構。InnoDB聚簇索引的葉子節(jié)點按主鍵值順序排列這就決定了主鍵的順序性極其重要。如果使用自增主鍵每次插入的新記錄主鍵值都比之前的大InnoDB只需要在聚簇索引的最右端追加新頁即可不需要移動已有數(shù)據(jù)。這種情況下的插入性能是最優(yōu)的。如果使用UUID作為主鍵麻煩就來了。UUID是隨機生成的字符串主鍵值在全局范圍是無序的新插入記錄的主鍵可能落在已有數(shù)據(jù)頁的中間位置。為了保持B樹有序InnoDB不得不把原數(shù)據(jù)頁分裂成兩半把新記錄插入到中間這個過程叫頁分裂。頁分裂不僅帶來額外的I/O和CPU開銷還會導致數(shù)據(jù)頁出現(xiàn)碎片和空洞使表空間膨脹。我做一個簡單的對比表格幫助理解對比維度自增主鍵UUID主鍵插入順序完全有序追加隨機分布頁分裂概率極低高二級索引占用小主鍵短大主鍵長分布式場景有沖突風險天然全局唯一數(shù)據(jù)遷移可能沖突無需改造那UUID是不是完全不能用也不是。如果在分布式場景下需要全局唯一的ID又沒法用數(shù)據(jù)庫自增我建議不要直接用隨機UUID而是用雪花算法Snowflake或改進的順序UUID。這類ID是趨勢遞增的雖然不完全連續(xù)但能顯著減少頁分裂。說到底主鍵的選擇是業(yè)務需求與存儲結構之間的平衡關鍵是要清楚每種方案的代價。4.2 回表、覆蓋索引和索引下推回表這個動作是理解二級索引性能的關鍵。假設有一張用戶表主鍵是id普通索引建在phone上。執(zhí)行SELECT * FROM users WHERE phone 138...時MySQL會先通過phone索引找到對應記錄的id值然后用這個id去聚簇索引里再查一次才能拿到完整行數(shù)據(jù)。第二次查詢就是回表。如果一次查詢命中了50行就可能發(fā)生50次回表這是不小的I/O開銷。覆蓋索引就是用來消除回表的。如果查詢需要的所有列都包含在一個二級索引里那么MySQL只需要遍歷這個索引本身就可以返回結果不需要回表。比如SELECT phone FROM users WHERE phone 138...phone索引已經(jīng)包含了phone列和id列要的數(shù)據(jù)都在索引里直接返回即可。Extra里顯示的Using index就是這個意思。索引下推Index Condition PushdownICP也是一個容易被忽略的優(yōu)化。在沒有ICP時MySQL使用二級索引查詢會先通過索引把所有可能的記錄主鍵拿回服務層再進行WHERE條件的過濾。而有了ICPMySQL允許在存儲引擎層直接根據(jù)索引中包含的字段做過濾減少回表次數(shù)。從MySQL 5.6開始這個特性默認開啟。EXPLAIN的Extra里出現(xiàn)Using index condition就是索引下推生效的標識。這三個機制放在一起理解其實是一個目標能不回表就不回表能少回表就少回表。因為回表意味著一次隨機磁盤I/O在機械硬盤時代代價尤其昂貴。4.3 關于頁分裂的補充實踐主鍵設計影響頁分裂這一點光記住結論不夠最好能在實際運維中觀察一次。我講一個常見現(xiàn)象某張表使用UUID主鍵業(yè)務量上去之后發(fā)現(xiàn)表空間大小遠超實際數(shù)據(jù)量碎片率也很高。用SHOW TABLE STATUS看到的Data_length明顯大于預期或者information_schema里的碎片統(tǒng)計很大就基本上可以判斷頁分裂和頁空洞已經(jīng)比較嚴重了。緩解措施除了換主鍵方案還可以定期做表的整理操作把碎片合并回收。當然更好的方式是從一開始就選擇有序的ID生成策略不要等到線上出現(xiàn)性能問題再補救。5. 索引相關的SQL“源碼”與面試高頻題5.1 可直接復用的索引操作SQL學了這么多原理最終還是要落到SQL上。下面我給出一套自己日常開發(fā)和排查索引問題時反復使用的SQL片段可以當作“源碼”直接復制調整。-- 建表時直接創(chuàng)建索引 CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, order_no VARCHAR(32) NOT NULL, status TINYINT NOT NULL DEFAULT 0, create_time DATETIME NOT NULL, -- 普通索引 INDEX idx_user_id (user_id), -- 唯一索引 UNIQUE INDEX uk_order_no (order_no), -- 聯(lián)合索引 INDEX idx_user_status (user_id, status) ) ENGINEInnoDB; -- 為已有表添加索引 ALTER TABLE orders ADD INDEX idx_create_time (create_time); -- 查看表的索引信息 SHOW INDEX FROM orders; -- 分析某條SQL是否走索引 EXPLAIN SELECT * FROM orders WHERE user_id 1001 AND status 1 ORDER BY create_time DESC; -- 強制走索引僅供測試生產(chǎn)慎用 SELECT * FROM orders FORCE INDEX (idx_user_id) WHERE user_id 1001; -- 刪除索引 DROP INDEX idx_create_time ON orders; -- 分析表更新優(yōu)化器統(tǒng)計信息 ANALYZE TABLE orders;EXPLAIN輸出里最需要關注的幾個字段是type、key、rows、Extra。type從好到差大致是system、const、eq_ref、ref、range、index、ALL?？吹紸LL基本就是全表掃描需要警覺。key表示實際使用的索引rows是預估掃描行數(shù)Extra如果出現(xiàn)Using index說明是覆蓋索引出現(xiàn)Using index condition說明用了索引下推出現(xiàn)Using filesort說明存在額外排序。我建議所有開發(fā)同學都把EXPLAIN用熟。拿到一條慢SQL我會習慣性地先看type是不是ALL再對比rows和實際行數(shù)最后看Extra里有沒有隱性問題。這套流程基本上能解決90%的MySQL單表慢查詢。5.2 索引面試高頻問答這里我把被問得最多的幾個索引問題做個匯總順便給出參考答案。為什么MySQL選擇B樹而不是B樹B樹的非葉子節(jié)點比B樹更“瘦”只存鍵不存數(shù)據(jù)所以同樣16KB的頁能容納更多鍵樹高更低I/O次數(shù)更少B樹的葉子節(jié)點用鏈表串聯(lián)范圍查詢和排序效率更高B樹的葉子節(jié)點之間沒有鏈表范圍查詢需要重復中序遍歷效率差很多。Hash索引比B樹快為什么不直接用Hash索引做等值查詢確實快時間復雜度接近O(1)但它只能處理等值匹配無法支持范圍查詢也不支持排序而且可能存在哈希沖突導致性能抖動。所以InnoDB里的哈希索引主要是自適應的由存儲引擎根據(jù)熱數(shù)據(jù)自動構建不需要也不建議開發(fā)人員手動創(chuàng)建。什么情況叫“最佳左前綴”而不是“最左前綴”其實是一個概念表達上以官方文檔為準。聯(lián)合索引從最左邊列開始連續(xù)匹配才能生效跳過某列后面的列就用不上。理解成“聯(lián)合索引的生效從最左開始連續(xù)”就夠了。為什么建議少用SELECT *SELECT *通常不是覆蓋索引所有非索引列都要回表。如果業(yè)務只需要兩三個字段盡量把字段列全或保證字段都被索引覆蓋能顯著減少回表量。索引一定能讓查詢變快嗎不一定。索引的本質是空間換時間也有維護成本。寫多讀少的表、數(shù)據(jù)量太小的表、區(qū)分度太低的列建索引可能得不償失。最終要看優(yōu)化器的代價評估。5.3 一個完整的慢查詢排查實戰(zhàn)最后分享一個實戰(zhàn)案例把這套方法串起來。某天收到告警用戶查詢接口出現(xiàn)大量慢SQL單次耗時超過3秒。原始SQL大致是這樣SELECT * FROM user_orders WHERE order_no LIKE %20240115% AND status 1;EXPLAIN之后發(fā)現(xiàn)typeALL、rows200萬order_no上有索引但沒被使用。問題一行就能看出來LIKE的通配符在開頭導致索引失效。我的處理分了三步第一步先確認業(yè)務需求。和產(chǎn)品確認后發(fā)現(xiàn)這個頁面的搜索框要求是“訂單號后6位精確匹配”不是任意位置模糊匹配。那問題就簡單了直接把查詢改成等值匹配SELECT * FROM user_orders WHERE order_no CONCAT(20240115, 123456);第二步如果確實需要做模糊搜索業(yè)務上可以接受的話加一個專門的冗余列存去掉前綴后的短單號再對這個短單號建索引?；蛘哂肐NSTR函數(shù)掃描但那是全表掃不適合大數(shù)據(jù)量。第三步為了防止后續(xù)上線的新查詢再次踩坑我把線上搜索接口的查詢全部review了一遍凡是LIKE通配符開頭的、函數(shù)包索引列的、隱式轉換的SQL全部整改。半年之后再看慢查詢列表這個接口再也沒出現(xiàn)過。這段經(jīng)歷讓我越來越覺得索引知識不能只停留在“建索引”這一步更重要的是理解數(shù)據(jù)結構、理解優(yōu)化器選擇、理解業(yè)務和存儲之間的權衡。只要你把這三個層面的邏輯打通了很多問題都不用背推理就能推出來。我個人在實際操作中的體會是索引優(yōu)化不是一次性的工作它是和業(yè)務增長同步演進的。數(shù)據(jù)量沒上來之前全表掃描也許完全夠用等數(shù)據(jù)量上來以后再小的優(yōu)化也會被放大成顯著的收益。所以建議大家在日常開發(fā)中養(yǎng)成先看執(zhí)行計劃的習慣每次都多問一句“這條SQL為什么沒走索引”長期積累下來你對MySQL的敏感度一定會比別人高出一截。