1. 先把“表”這件事想清楚字段、類型與約束只要是接觸過MySQL的人應該都有過這種經(jīng)歷剛開始建表時特別隨意字段類型憑感覺選約束能不加就不加等業(yè)務跑了大半年數(shù)據(jù)量上來之后才發(fā)現(xiàn)一堆歷史遺留問題——查詢慢、亂碼、數(shù)據(jù)對不上、沒法統(tǒng)計。再回頭改表結構又怕鎖表影響線上業(yè)務。所以聊MySQL表操作和查詢之前我想先說說建表階段那些容易被忽略、但影響極其深遠的基礎設計問題。畢竟表結構設計得是否合理直接決定后面所有查詢語句好不好寫、跑得快不快。1.1 字段類型選錯了后面全是淚字段類型是表結構里最基礎但也最容易出錯的地方。很多新手喜歡“省事”所有字符串一律用varchar(255)所有數(shù)值一律用int日期就放一個字符串字段存進去。短期看確實沒問題等數(shù)據(jù)量到了幾百萬行各種問題就來了字符串類型的日期沒法直接用日期函數(shù)做范圍統(tǒng)計int存不下手機號直接溢出varchar(255)在utf8mb4字符集下單字段索引長度超限導致索引失效。這里我直接給一套常用的選型參考整數(shù)能用int就別用bigint能用tinyint就別用int。狀態(tài)值、開關值用tinyint主鍵用bigint還是int取決于業(yè)務量預估但不要一拍腦袋就給所有表都上bigint。小數(shù)不要用float和double存金額精度丟失的問題在實際項目中非常坑。用decimal比如decimal(10,2)10表示總位數(shù)2表示小數(shù)位。字符串定長的用char比如身份證號、手機號這種長度固定的變長的用varchar但要給合理的最大長度別一上來就255。長文本用text但要注意text字段不能有默認值索引也只能前綴索引。日期時間這個特別值得多說一句。強烈建議用datetime不要用timestamp因為timestamp有2038年的上限問題。另外不要用字符串存日期雖然看起來方便但丟了時間函數(shù)的便利性也無法利用索引做高效的區(qū)間查詢。有人可能會問datetime和timestamp到底差在哪。簡單說timestamp存儲的是UTC時間存的時候會轉時區(qū)取的時候也會轉回來受時區(qū)設置影響datetime存的就是字面時間不涉及時區(qū)轉換。對于業(yè)務系統(tǒng)來說大多數(shù)情況下datetime更直觀、更可控避免因為數(shù)據(jù)庫時區(qū)和應用時區(qū)不一致造成數(shù)據(jù)錯亂。1.2 約束與索引建表時一次想好別等數(shù)據(jù)量大了再回頭約束是很多人建表時最容易忽略的東西。常見的主鍵約束、唯一約束、非空約束、默認值約束以及外鍵約束我發(fā)現(xiàn)很多項目干脆一個外鍵都不用。不用的原因也簡單外鍵在寫入的時候有額外的校驗開銷分布式拆分表的時候也麻煩所以業(yè)務系統(tǒng)基本都靠應用層來保證關聯(lián)數(shù)據(jù)的完整性。這可以理解但至少主鍵、唯一鍵、非空、默認值這些基礎約束該加就得加。主鍵的選擇上我建議用自增int/bigint作為主鍵業(yè)務字段不要直接當主鍵。原因有兩個一是InnoDB是聚簇索引組織表主鍵是物理存儲的順序依據(jù)自增主鍵能保證插入時順序寫入減少頁分裂二是業(yè)務字段的變更不可控拿手機號當主鍵哪天允許用戶改綁手機號整個索引結構都得跟著動。唯一約束這塊要注意它和普通索引的區(qū)別。唯一約束本身就是索引只是額外加了唯一性校驗。所以如果業(yè)務上需要保證某個字段唯一直接加unique key不要用普通索引之后再在應用層做查詢校驗既慢又容易有并發(fā)漏洞。還有個很實用的習慣每張表都加上創(chuàng)建時間和更新時間兩個字段類型用datetime更新時間可以靠業(yè)務代碼維護也可以建表時用ON UPDATE CURRENT_TIMESTAMP自動更新。這兩個字段在排查數(shù)據(jù)問題時幾乎是救命稻草尤其是出現(xiàn)臟數(shù)據(jù)、重復數(shù)據(jù)、異常數(shù)據(jù)的時候能迅速定位出問題時間點。1.3 字符集與排序規(guī)則亂碼和排序不對的頭號原因字符集問題可以說是MySQL新手時期最常遇到的坑之一。我記得第一次接手一個老項目明明代碼里都是UTF-8數(shù)據(jù)庫里卻出現(xiàn)一串問號和亂碼排查了半天最后發(fā)現(xiàn)庫的默認字符集是latin1。這種問題一旦上線之后再想改代價非常大。所以在建庫建表的時候第一件事就是明確字符集?，F(xiàn)在的統(tǒng)一標準就是utf8mb4注意不是utf8。MySQL里的utf8是utf8mb3的別名只支持最多3字節(jié)的字符像emoji這種4字節(jié)字符就存不了會報錯或者變成亂碼。utf8mb4才是真正的“完整UTF-8”兼容所有Unicode字符。排序規(guī)則也要一并確認。utf8mb4_general_ci和utf8mb4_unicode_ci是兩種常見選擇。前者排序快但精度略差后者排序更準確但稍微慢一點。絕大多數(shù)業(yè)務系統(tǒng)其實用哪個差別都不大需要重點注意的是別出現(xiàn)表、庫、連接層字符集不一致的情況。判斷起來也簡單執(zhí)行一次查詢如果發(fā)現(xiàn)中文亂碼先別急著改數(shù)據(jù)從客戶端連接、到數(shù)據(jù)庫連接、再到表和字段的字符集一層層排查。最常見的坑是連接層用了utf8而表和字段是utf8mb4中文正常遇到特殊字符就出問題。2. 建表、改表、刪表一張表的完整生命周期管理前面說了設計層面的問題接下來就進入實際操作環(huán)節(jié)。表操作無非就是建表、改表、刪表這三類但每一類里都有不少細節(jié)值得展開。很多人寫SQL的時候只關心能不能跑通忽略了操作帶來的影響面尤其是生產(chǎn)環(huán)境里一條ALTER TABLE就可能把整個業(yè)務拖垮。2.1 建表從需求到DDL落地的實操寫法先看一個實際的建表示例。假設要建一張用戶訂單表包含訂單號、用戶ID、商品名稱、訂單金額、訂單狀態(tài)、創(chuàng)建時間、更新時間這些基本字段。第一版DDL可以這樣寫CREATE TABLE orders ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主鍵ID, order_no VARCHAR(64) NOT NULL COMMENT 訂單號, user_id BIGINT NOT NULL COMMENT 用戶ID, product_name VARCHAR(128) NOT NULL COMMENT 商品名稱, amount DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 訂單金額, status TINYINT NOT NULL DEFAULT 0 COMMENT 訂單狀態(tài)0待支付 1已支付 2已取消, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 創(chuàng)建時間, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新時間, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id), KEY idx_created_at (created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_general_ci COMMENT用戶訂單表;這個建表語句里的幾個細節(jié)值得展開說明一下。首先是ENGINEInnoDBMySQL 5.7之后默認就是InnoDB但寫出來更明確。InnoDB支持事務、行級鎖、崩潰恢復是絕大多數(shù)業(yè)務場景的唯一選擇。有些人可能聽說過MyISAM查詢快但它不支持事務、不支持行鎖寫并發(fā)一高就全線阻塞真不適合業(yè)務系統(tǒng)用。其次是每個字段都加了COMMENT注釋。這個習慣非常好。一個項目壽命往往遠超想象兩三年后你自己回頭維護這張表如果沒有注釋真的會想不起來某個字段是干什么用的。更不用說團隊協(xié)作別人接手你的表結構時良好的注釋能省下大量溝通成本。再注意到status字段用的是TINYINT而不是VARCHAR或者ENUM。用數(shù)字表示狀態(tài)擴展性好0、1、2不夠用隨時可以加。但這里有個小建議數(shù)字狀態(tài)值一定要配注釋說明含義否則時間長了沒人知道1代表什么。不過更推薦的做法是在應用層代碼里定義狀態(tài)常量注釋輔助解釋兩邊對應著看。2.2 ALTER TABLE加字段、改字段、加索引的常見操作業(yè)務迭代過程中表結構幾乎一定會變。ALTER TABLE的語法比較簡單但生產(chǎn)環(huán)境里要特別注意執(zhí)行成本和鎖表風險。加字段是最常見的操作。比如給訂單表加一個支付時間字段ALTER TABLE orders ADD COLUMN paid_at DATETIME DEFAULT NULL COMMENT 支付時間 AFTER status;這里有一個非常實用的習慣把新字段用AFTER關鍵字放在相關字段旁邊而不是默認加到最后。雖然最終效果不影響查詢但看表結構時邏輯會更清晰。另外注意在數(shù)據(jù)量很大的表上執(zhí)行ALTER TABLEInnoDB需要重建表會鎖住寫操作耗時可能非常長甚至導致主從延遲。直到MySQL 5.6引入了在線DDL加上MySQL 8.0的進一步優(yōu)化很多ALTER操作已經(jīng)不會完全鎖表了但字段類型變更、修改字符集這類操作仍然可能很重。所以在生產(chǎn)環(huán)境做表結構變更前我一般會先確認表的行數(shù)和當前實例的負載盡量挑業(yè)務低峰期操作。修改字段類型和默認值也是高頻操作。語法如下ALTER TABLE orders MODIFY COLUMN status TINYINT NOT NULL DEFAULT 1 COMMENT 訂單狀態(tài)0待支付 1已支付 2已取消 3已退款;同樣一個MODIFY操作看似簡單但如果表很大執(zhí)行期間同樣是有代價的。而且MODIFY COLUMN會改變字段的整條定義如果你只寫了一部分屬性其他屬性會被重置所以執(zhí)行前最好先用SHOW CREATE TABLE把原有定義完整看一下再確認要改的信息避免誤把已有的NOT NULL、DEFAULT等屬性弄丟。加索引的常見操作ALTER TABLE orders ADD INDEX idx_user_created (user_id, created_at);這是一個典型的聯(lián)合索引能夠同時優(yōu)化“查某個用戶的訂單按時間倒序”這類高頻查詢。聯(lián)合索引的核心設計原則是區(qū)分度高的字段放前面等值查詢字段放前面范圍查詢字段放后面。這個后面講到查詢優(yōu)化時還會再展開。2.3 刪表與清空DROP / TRUNCATE / DELETE的本質區(qū)別刪表有三種方式很多人分不清它們的適用場景。DROP TABLE是整張表直接刪掉表結構、數(shù)據(jù)、索引全部消失不可恢復。TRUNCATE TABLE是清空數(shù)據(jù)但保留表結構相當于重置這張表不可按條件刪也不能回滾。DELETE FROM是逐行刪除可以帶WHERE條件且走事務可以回滾。所以日常開發(fā)中真正不要這張表了才用DROP想要快速清空一張臨時表或日志表的數(shù)據(jù)用TRUNCATE刪除符合條件的部分數(shù)據(jù)用DELETE。這里特別提一個問題很多人誤以為DELETE之后數(shù)據(jù)量還是沒降下來。這是因為InnoDB刪除的行標記為“已刪除”但物理空間沒有被立即釋放后續(xù)有新數(shù)據(jù)插入時才會復用這些空間。如果只是跑了一次DELETE FROM大表磁盤空間不變是很正常的不要慌張。想要真正收縮表空間可以執(zhí)行OPTIMIZE TABLE或者ALTER TABLE ... ENGINEInnoDB來重建表但這又是一個重操作生產(chǎn)環(huán)境慎用。3. 單表查詢SELECT的核心邏輯與執(zhí)行順序聊完表操作進入查詢部分。查詢是MySQL里最日常、也最考驗功力的操作。很多人寫了幾年的SQL遇到慢查詢還是只會加索引其實很多問題的根源不在于缺索引而在于沒有真正理解SELECT的執(zhí)行邏輯。3.1 SELECT語法順序與執(zhí)行順序是兩碼事這是個老生常談卻又極其重要的話題。一條完整的SELECT語句書寫的順序是SELECT 字段 FROM 表 WHERE 條件 GROUP BY 分組字段 HAVING 分組后條件 ORDER BY 排序字段 LIMIT 偏移量, 行數(shù)但SQL真正執(zhí)行的順序不是這個。MySQL會先走FROM找到數(shù)據(jù)源然后WHERE過濾原始數(shù)據(jù)再GROUP BY分組之后HAVING過濾分組結果接著SELECT投影目標字段然后ORDER BY排序最后LIMIT截取。理解這個執(zhí)行順序最直接的好處是能解釋很多“奇怪”的現(xiàn)象。比如WHERE條件里不能用SELECT中定義的別名因為WHERE執(zhí)行時SELECT還沒執(zhí)行別名自然不存在。而ORDER BY可以用別名因為排序發(fā)生在SELECT之后。再比如為什么GROUP BY之后SELECT能用的字段要么是分組字段要么是聚合函數(shù)的結果因為分組后每組只保留一行其他字段的值可能有多條MySQL無法確定取哪個在嚴格模式下會直接報錯。我見過一個很典型的案例某個統(tǒng)計報表里SQL寫得特別長里面在WHERE里判斷了一個用CASE WHEN生成的別名結果一直報錯。我當時給出的修改方案就是把那個判斷挪到HAVING里或者在外面再包一層子查詢問題立刻解決。這種問題如果不懂執(zhí)行順序光看報錯信息很難定位。3.2 WHERE過濾條件的類型陷阱和經(jīng)驗寫法WHERE是查詢中最常用、也最容易埋坑的子句。最常見的一個坑是類型不一致導致索引失效。比如表里user_id是VARCHAR類型但查詢時傳了一個數(shù)字MySQL會把字符串類型字段隱式轉換成數(shù)字來比較導致該字段上的索引無法使用。反過來也一樣如果字段是INT類型查詢條件里傳了字符串同樣存在隱式轉換。所以一條基礎經(jīng)驗是字段類型和條件值類型保持一致別讓MySQL幫你做隱式轉換。還有一個常見問題是函數(shù)包裹字段。比如在創(chuàng)建時間字段上寫了WHERE DATE(created_at) 2024-01-01乍一看沒毛病但實際上DATE()函數(shù)讓created_at無法直接使用索引MySQL不得不對每一行執(zhí)行函數(shù)計算然后再過濾。正確寫法是改成范圍條件WHERE created_at 2024-01-01 AND created_at 2024-01-02這是一個非常高頻的優(yōu)化點凡是出現(xiàn)“查詢慢但明明加了索引還是慢”的情況第一反應就應該是檢查WHERE條件里有沒有對索引字段使用函數(shù)或者做了隱式轉換。如果要表達得更嚴謹一點想讓索引生效就要讓索引字段保持“裸狀態(tài)”不做任何包裹計算。3.3 GROUP BY與HAVING分組統(tǒng)計的正確姿勢GROUP BY用于對數(shù)據(jù)進行分組統(tǒng)計是報表類需求的基石。比如統(tǒng)計每天訂單數(shù)SELECT DATE(created_at) AS day, COUNT(*) AS order_count FROM orders WHERE created_at 2024-01-01 GROUP BY day ORDER BY day;注意這里的DAY這個別名在GROUP BY和ORDER BY里都能用因為這兩步都發(fā)生在SELECT之后。這個寫法在MySQL里是允許的而且很常見。GROUP BY和HAVING經(jīng)常一起出現(xiàn)HAVING用于對分組后的結果再做過濾。很多人會把HAVING和WHERE搞混記一個簡單的區(qū)別WHERE在分組之前過濾行HAVING在分組之后過濾分組。WHERE不能使用聚合函數(shù)HAVING可以。比如要找出訂單數(shù)超過100的用戶IDSELECT user_id, COUNT(*) AS order_count FROM orders GROUP BY user_id HAVING order_count 100;這條SQL是先按用戶分組統(tǒng)計再過濾出訂單數(shù)大于100的用戶。如果把這個條件放到WHERE里就會直接報錯因為COUNT的值在WHERE階段根本還沒算出來。還有一點要注意HAVING的效率通常比WHERE差因為HAVING要等分組完成才能過濾所以能用WHERE提前過濾的數(shù)據(jù)盡量在WHERE階段就過濾掉減少分組壓力。3.4 ORDER BY與LIMIT排序、分頁與深分頁優(yōu)化排序和分頁是日常接口開發(fā)里離不開的操作。最簡單的查詢SELECT * FROM orders WHERE user_id 10001 ORDER BY created_at DESC LIMIT 20;這里有一個聯(lián)合索引設計的最佳實踐如果這個查詢是高頻的可以建一個(user_id, created_at)的聯(lián)合索引這樣WHERE定位到用戶后索引內部已經(jīng)按created_at排好序了直接取前20條就行省去排序環(huán)節(jié)。這就是前面建表部分提到聯(lián)合索引設計原則的應用。LIMIT的分頁寫法也很常見但深分頁是個隱藏的大坑。比如SELECT * FROM orders ORDER BY id LIMIT 1000000, 20;這條SQL會把前100萬條數(shù)據(jù)都查出來然后丟棄只留下最后的20條。偏移量越大查詢越慢而且是線性增長的。解決思路有幾種。第一種是記錄上一次查詢的最大ID下次查詢帶上WHERE id 上次最大ID的條件用延遲關聯(lián)或索引覆蓋的方式去翻頁。第二種是子查詢先取偏移段的ID列表再回表拿完整數(shù)據(jù)SELECT * FROM orders WHERE id ( SELECT id FROM orders ORDER BY id LIMIT 1000000, 1 ) ORDER BY id LIMIT 20;這種方式先用索引快速定位到第1000001條的位置再往后取20條比直接LIMIT 1000000, 20高效得多。但要注意這種優(yōu)化方案只適用于有自增主鍵且數(shù)據(jù)沒有頻繁物理刪除的場景如果數(shù)據(jù)有大量隨機刪除ID之間的空洞會讓分頁結果不一致。實際項目中需要結合業(yè)務場景權衡。4. 多表查詢JOIN、子查詢、UNION怎么選單表查詢解決的是單個數(shù)據(jù)源的問題但業(yè)務需求往往需要關聯(lián)多張表。多表查詢的實現(xiàn)方式有三種JOIN、子查詢、UNION。每種方式都有各自的適用場景沒有絕對的好壞關鍵是要理解它們的執(zhí)行邏輯。4.1 JOIN家族INNER、LEFT、RIGHT的區(qū)別與場景JOIN是關聯(lián)查詢最核心的寫法。最常見的三種是INNER JOIN、LEFT JOIN、RIGHT JOIN。網(wǎng)上有很多圖解釋它們的區(qū)別這里我用實際業(yè)務來舉例說明。假設有兩張表用戶表users和訂單表orders。想知道“哪些用戶下過單”用INNER JOIN只返回兩邊都匹配的行SELECT users.id, users.name, orders.order_no FROM users INNER JOIN orders ON users.id orders.user_id;想知道“每個用戶和他的所有訂單沒下過單的用戶也要顯示出來”用LEFT JOIN左表數(shù)據(jù)全部保留右表無匹配就以NULL填充SELECT users.id, users.name, orders.order_no FROM users LEFT JOIN orders ON users.id orders.user_id;這個場景最常見的就是列表頁需要展示主表數(shù)據(jù)即使副表沒數(shù)據(jù)也要顯示一行。RIGHT JOIN的用法和LEFT JOIN對稱以右表為主但實際開發(fā)中用得很少。我個人的建議是統(tǒng)一用LEFT JOIN就好不要混用RIGHT JOIN否則SQL的可讀性會變差團隊同事看代碼也不舒服。關聯(lián)條件上有一個極其重要的坑LEFT JOIN中如果在WHERE里對右表字段加過濾條件會導致“左表保留全部行”的語義被破壞。舉例SELECT users.id, users.name, orders.order_no FROM users LEFT JOIN orders ON users.id orders.user_id WHERE orders.status 1;這條SQL的意圖可能是“查所有用戶中已支付訂單的關聯(lián)情況”但實際執(zhí)行時因為WHERE在JOIN之后過濾已經(jīng)把左表中沒有匹配訂單的用戶行全部剔除了LEFT JOIN變成了INNER JOIN的效果。想要保持左表全部保留應該把過濾條件寫在ON子句里SELECT users.id, users.name, orders.order_no FROM users LEFT JOIN orders ON users.id orders.user_id AND orders.status 1;這個細節(jié)我已經(jīng)在真實項目中碰到不止一次每次都是面試題級別的經(jīng)典陷阱而且業(yè)務上一旦踩中定位問題往往要花不少時間。4.2 子查詢與JOIN的取舍子查詢是嵌套在主查詢里的SELECT語句可以分為FROM子句里的子查詢、 WHERE子句里的子查詢、SELECT子句里的標量子查詢幾種。比如要查“每個用戶最近一筆訂單”可以用關聯(lián)子查詢的方式SELECT o.* FROM orders o WHERE o.id ( SELECT MAX(id) FROM orders o2 WHERE o2.user_id o.user_id );這個寫法理解起來比較簡單但它對每條訂單都會執(zhí)行一次子查詢如果數(shù)據(jù)量大性能會很差。還有一類常見的子查詢是用IN比如SELECT * FROM users WHERE id IN (SELECT user_id FROM orders WHERE amount 100);這種寫法的隱患是如果子查詢返回的結果集特別大IN列表會非常長效率不高。而且某些MySQL版本對IN子查詢的優(yōu)化做得不夠好執(zhí)行計劃可能會退化成全表掃描。更穩(wěn)健的做法是用EXISTS改寫或者改成JOINSELECT DISTINCT users.* FROM users INNER JOIN orders ON users.id orders.user_id AND orders.amount 100;用JOIN的語義更直白執(zhí)行計劃可控性也更高。當然JOIN之后如果主表數(shù)據(jù)有重復關聯(lián)需要加上DISTINCT去重這時要自己確認是否會產(chǎn)生重復行。子查詢和JOIN的選擇沒有絕對標準我的經(jīng)驗是小數(shù)據(jù)量、語義直觀的子查詢可以用大數(shù)據(jù)量、性能敏感的查詢優(yōu)先考慮JOIN和EXISTS然后通過EXPLAIN確認執(zhí)行計劃。4.3 UNION與UNION ALL別讓去重拖慢查詢UNION和UNION ALL都是將多個SELECT的結果集合并輸出。區(qū)別在于UNION會去重UNION ALL不去重。這一字之差性能差距可能非常明顯因為去重意味著需要對整個結果集排序或走哈希去重額外開銷極大。業(yè)務上如果明確兩個結果集不可能有重復或者重復無害直接用UNION ALL就沒問題了。舉一個實際場景要查“訂單金額大于1000的訂單”和“最近7天創(chuàng)建的訂單”的合并列表。兩個條件有交叉的可能但最終展示訂單列表時重復也沒關系所以SELECT order_no, created_at FROM orders WHERE amount 1000 UNION ALL SELECT order_no, created_at FROM orders WHERE created_at NOW() - INTERVAL 7 DAY;這樣比UNION快不少而且邏輯更符合業(yè)務預期。另外還有一個容易被忽略的事項UNION的子句之間各SELECT返回的列數(shù)和數(shù)據(jù)類型必須一致否則MySQL會報錯。比如第一個SELECT返回了兩列第二個SELECT返回了三列直接編譯失敗。如果各表中列名不一致第一個SELECT的列名會作為結果集的列名。5. 提升查詢性能的關鍵索引與執(zhí)行計劃前面講了很多查詢寫法但真正跑線上查詢的時候性能怎么樣不能靠猜得靠數(shù)據(jù)說話。這一部分重點說索引的坑和EXPLAIN執(zhí)行計劃的用法。5.1 索引失效的幾種常見姿勢索引失效是慢查詢的頭號原因。我總結過幾條高頻踩坑場景基本覆蓋了日常開發(fā)里90%的問題。第一對索引列使用函數(shù)或表達式計算。前面已經(jīng)提過WHERE DATE(created_at) 2024-01-01會導致索引失效。同樣地WHERE amount 1 100這種寫法也會讓amount字段的索引失效。第二隱式類型轉換。varchar字段和數(shù)字比較、int字段和字符串比較都會讓MySQL放棄索引。第三LIKE模糊匹配以%開頭。比如WHERE name LIKE %張%因為無法確定前綴B樹無法定位只能全表掃。反過來WHERE name LIKE 張%可以走索引。第四聯(lián)合索引不使用最左前綴。建了(a, b, c)聯(lián)合索引條件里直接查b1跳過a索引用不上。這是最左前綴原則決定的。在設計聯(lián)合索引時一定要把最高頻的等值查詢字段放最左邊。第五OR條件導致索引失效。比如WHERE a 1 OR b 2如果只有a字段有索引MySQL可能選擇全表掃描。優(yōu)化方式是把OR改成UNION或者給b也加上索引。第六對NULL值的判斷。WHERE name IS NULL不一定導致索引失效但WHERE name IS NOT NULL在很多場景下優(yōu)化器會認為返回數(shù)據(jù)量太大直接放棄索引。這里沒有絕對結論實際操作中以EXPLAIN結果為準。第七ORDER BY和GROUP BY的字段順序與索引順序不一致。比如聯(lián)合索引(a, b)但SQL里ORDER BY b, a索引順序不匹配排序走文件排序性能下降。5.2 EXPLAIN怎么看重點字段速查EXPLAIN是排查慢查詢的核心工具。用法很簡單在SELECT前面加個EXPLAIN關鍵字就行EXPLAIN SELECT * FROM orders WHERE user_id 10001 AND created_at 2024-01-01;返回結果里重點看這幾個字段type訪問類型。從好到差依次是const、eq_ref、ref、range、index、ALL。出現(xiàn)ALL表示全表掃描要高度警惕。range說明掃描了一個索引范圍比全表掃描好得多。key實際用到的索引名。如果為NULL說明沒走索引。rows預估掃描的行數(shù)。這個數(shù)越大查詢通常越慢。Extra額外信息。出現(xiàn)Using filesort或Using temporary說明排序或分組用了臨時文件性能往往不佳出現(xiàn)Using index則說明是覆蓋索引性能很好。舉個實際排查案例某次線上接口變慢EXPLAIN結果顯示一條查詢的type為ALLrows達到500多萬。打開SQL一看WHERE條件里對create_time用了DATE()函數(shù)。改成范圍條件后type變成rangerows降到幾千接口響應時間從接近2秒降到幾十毫秒。這就是EXPLAIN的價值——用數(shù)據(jù)定位問題而不是拍腦袋猜。5.3 一個真實慢查詢優(yōu)化案例之前處理過某業(yè)務系統(tǒng)的一個慢查詢是訂單列表接口。SQL大概長這樣SELECT id, order_no, user_id, amount, status, created_at FROM orders WHERE user_id 12345 ORDER BY created_at DESC LIMIT 10;表里訂單量接近千萬user_id和created_at各自都是獨立索引但查詢依然慢。EXPLAIN之后發(fā)現(xiàn)優(yōu)化器在兩個索引之間選擇了一個但Extra里出現(xiàn)了Using filesort也就是排序沒有完全走索引。原因很簡單優(yōu)化器走的是idx_user_id先定位到該用戶的所有訂單再對這些訂單按created_at排序。因為created_at不滿足索引順序排序操作只能在內存或磁盤上做數(shù)據(jù)量一大就慢。解決方案就是前面提到的聯(lián)合索引ALTER TABLE orders ADD INDEX idx_user_created (user_id, created_at);這個聯(lián)合索引既能通過user_id快速定位又能在索引內部天然按created_at排好序完美匹配ORDER BY的需求。加上索引之后EXPLAIN顯示Using filesort消失查詢時間從幾百毫秒降到個位數(shù)毫秒。這個案例值得記住的不是SQL寫法本身而是索引設計要兼顧WHERE和ORDER BY。很多人在聯(lián)合索引上只考慮過濾字段忽略了排序字段結果WHERE很快但ORDER BY把整個查詢拖慢。6. 常見問題與排查技巧實錄最后把這些年在MySQL表操作和查詢這塊遇到的高頻問題統(tǒng)一整理成一張速查表方便大家在實際開發(fā)中對號入座。癥狀可能原因排查思路解決方向中文亂碼字符集不一致或連接層字符集不對檢查庫、表、字段、連接的字符集統(tǒng)一為utf8mb4重建連接并確認character_set_server查詢越來越慢缺索引、索引失效或掃描行數(shù)過多執(zhí)行EXPLAIN看type、rows、key補聯(lián)合索引、改寫條件、避免函數(shù)包裹加了索引還是慢索引列被函數(shù)包裹、隱式類型轉換或OR條件檢查WHERE里索引列是否“裸狀態(tài)”去掉函數(shù)/轉換OR改為UNION或補索引排序慢索引順序與ORDER BY不匹配看Extra是否有Using filesort設計聯(lián)合索引時把排序字段放進去LIMIT翻頁到后面很慢深分頁在大偏移量下掃描大量無用行分析偏移量大小、掃描行數(shù)用ID定位、延遲關聯(lián)或減少偏移量DELETE后表空間不減少InnoDB的已刪除行空間未立即釋放查看表大小、碎片情況定期OPTIMIZE TABLE或接受空間復用機制同一查詢不同環(huán)境結果不同字符集、排序規(guī)則或數(shù)據(jù)分布差異對比兩邊的表結構定義和數(shù)據(jù)分布用小數(shù)據(jù)量復現(xiàn)并對比執(zhí)行計劃GROUP BY報錯沒開啟嚴格模式或SELECT字段與GROUP BY字段不匹配查看sql_mode配置和SQL寫法把非分組字段改為聚合函數(shù)或加入GROUP BY關聯(lián)查詢數(shù)據(jù)量暴增JOIN條件產(chǎn)生笛卡爾積檢查ON條件是否缺失或條件過寬確認關聯(lián)字段有索引條件收窄查詢結果包含重復數(shù)據(jù)JOIN一對一關系變一對多檢查關聯(lián)表的唯一性、關聯(lián)鍵是否有重復加DISTINCT或調整關聯(lián)SQL排查問題的時候有一個實用心法不要一上來就改SQL。先花兩分鐘看表結構再執(zhí)行EXPLAIN看執(zhí)行計劃最后才動手改。大多數(shù)慢查詢問題在執(zhí)行計劃階段就能露出馬腳改SQL只是收尾動作。還有一個經(jīng)驗之談排查過程中把當時的表結構、數(shù)據(jù)量、SQL語句、執(zhí)行計劃這四個信息記錄下來問題解決之后再回頭復盤一段時間下來自己解決問題的能力會提升一大截。表操作和查詢是MySQL最基礎的能力但也是最值得反復打磨的能力。工作中見到過太多“上線前沒問題跑了一段時間之后突然慢得出奇”的案例究其原因多數(shù)不是SQL本身的問題而是表結構設計和查詢方式對數(shù)據(jù)增長的適應性不足。比如索引設計沒考慮到數(shù)據(jù)規(guī)模的增長、表結構變更沒有預留彈性、深分頁沒有提前做容量規(guī)劃。所以我的經(jīng)驗是寫建表DDL和查詢SQL的時候多問自己一句這個表和這條SQL在數(shù)據(jù)量再漲十倍、漲百倍之后還能不能撐住帶著這個意識去寫每一行SQL能避掉絕大部分性能坑。最后再分享一個小技巧每張業(yè)務表都留一個自增主鍵和創(chuàng)建時間字段這兩個字段雖然平淡卻是后續(xù)排查問題時最可靠的抓手。