說實(shí)話MySQL 的 DDL、DML、DQL 這三類語(yǔ)句我是反反復(fù)復(fù)學(xué)了好幾遍才算是真正吃透的。早幾年我靠的是死記硬背把建表語(yǔ)法背得滾瓜爛熟結(jié)果遇到稍微復(fù)雜一點(diǎn)的查詢需求照樣卡殼。3月4號(hào)那天我換了個(gè)學(xué)法把這三個(gè)部分拆開帶著問題去問 AI讓 AI 給我生成示例、解釋執(zhí)行順序、甚至幫我排查報(bào)錯(cuò)一天下來記了滿滿十幾頁(yè)筆記效果比我之前啃一周文檔都好。這篇內(nèi)容就是把那天的學(xué)習(xí)過程重新整理了一遍重點(diǎn)講清楚 DDL 怎么建表、DML 怎么安全地改數(shù)據(jù)、DQL 怎么寫查詢才能不出錯(cuò)不走偏順便也聊聊我是怎么用 AI 輔助學(xué)習(xí)的。不管你是剛接觸數(shù)據(jù)庫(kù)的新手還是想系統(tǒng)復(fù)習(xí)一下的開發(fā)者這篇筆記應(yīng)該都能給你省下不少自己摸索的時(shí)間。1. 為什么我選擇用AI來啃MySQL的基礎(chǔ)語(yǔ)句1.1 學(xué)MySQL最痛苦的地方不是語(yǔ)法難其實(shí) SQL 語(yǔ)法本身并不難CREATE TABLE 就那幾個(gè)關(guān)鍵詞SELECT 再多也就十來個(gè)子句。真正的難點(diǎn)有三個(gè)第一知識(shí)點(diǎn)非常零散今天學(xué)個(gè)建表明天學(xué)個(gè)連接查詢之間沒有建立聯(lián)系遇到實(shí)際問題不知道從哪下手第二很多細(xì)節(jié)是文檔里不會(huì)直接告訴你的比如字符集不一致導(dǎo)致的亂碼、MySQL 5.7 和 8.0 在排序規(guī)則上的差異、GROUP BY 在 ONLY_FULL_GROUP_BY 模式下的行為這種東西光靠看教程根本踩不到第三缺少有效的反饋機(jī)制寫錯(cuò)了自己也看不出來甚至寫出來的 SQL 能跑但邏輯是錯(cuò)的數(shù)據(jù)結(jié)果不對(duì)你根本不記得去驗(yàn)證。我以前的學(xué)習(xí)方式是一頁(yè)一頁(yè)翻官方文檔效率低不說還經(jīng)常被長(zhǎng)難句勸退。后來我發(fā)現(xiàn)把 AI 當(dāng)成一個(gè)隨叫隨到的陪練反而更有效它能根據(jù)我的需求現(xiàn)場(chǎng)生成示例能解釋一段復(fù)雜 SQL 的每一步在干什么還能在我搞不清楚報(bào)錯(cuò)信息的時(shí)候幫忙拆解。這就不是看書而是有人在旁邊帶著你實(shí)操。1.2 AI在SQL學(xué)習(xí)中的三種高效打開方式我用 AI 學(xué) SQL 主要就三種姿勢(shì)都很實(shí)用。一種是概念問答式。遇到不理解的術(shù)語(yǔ)比如事務(wù)隔離級(jí)別、MVCC、聚集索引直接丟給 AI讓它用大白話解釋再給一個(gè)具體的場(chǎng)景。就拿事務(wù)隔離級(jí)別來說我要的是臟讀是什么、不可重復(fù)讀是什么、幻讀又是什么這種能對(duì)應(yīng)到真實(shí)故事的答案而不是教科書定義。AI 在這方面比搜索引擎好使因?yàn)榭梢赃B續(xù)追問一直問到真正搞懂。第二種是示例生成式。我給 AI 一個(gè)業(yè)務(wù)場(chǎng)景比如設(shè)計(jì)一個(gè)簡(jiǎn)單的訂單表包含訂單號(hào)、用戶ID、商品ID、數(shù)量、單價(jià)、創(chuàng)建時(shí)間讓它給出完整的建表 SQL然后我再一句一句分析每個(gè)字段為什么這么定義。這種方式等于把 AI 當(dāng)成出題老師它出題我批改。第三種是錯(cuò)誤排查式。把出錯(cuò)的 SQL 語(yǔ)句和報(bào)錯(cuò)信息丟給 AI請(qǐng)它分析可能的原因并給出修正版本。這個(gè)對(duì)新手特別友好因?yàn)?SQL 的報(bào)錯(cuò)有時(shí)候很抽象比如 Unknown column、You have an error in your SQL syntax自己盯著看半小時(shí)發(fā)現(xiàn)不了問題AI 幾秒鐘就能定位到具體位置。這三種方式我后面都會(huì)結(jié)合具體的語(yǔ)句種類再展開。1.3 我的AI學(xué)習(xí)工作流提問、驗(yàn)證、復(fù)盤我習(xí)慣的學(xué)習(xí)流程可以拆成三步簡(jiǎn)單說就是提問、驗(yàn)證、復(fù)盤缺一不可。第一步提問。我會(huì)把需求寫得盡量具體比如不說幫我寫個(gè)查詢而是說我有三張表用戶表、訂單表、訂單明細(xì)表希望查出來每個(gè)用戶的訂單總金額并且按金額從高到低排序金額相同的按用戶注冊(cè)時(shí)間排序用戶沒有訂單也要保留。需求越具體AI 生成的 SQL 就越接近可用的版本。第二步驗(yàn)證。AI 生成的 SQL 絕不能直接抄進(jìn)生產(chǎn)環(huán)境。我會(huì)先在本地 MySQL 里把表和測(cè)試數(shù)據(jù)建好跑一遍看結(jié)果是不是我想要的然后再用 EXPLAIN 看執(zhí)行計(jì)劃?rùn)z查有沒有可能拖慢查詢的地方。這一步是為了培養(yǎng)自己的判斷力而不是變成 AI 的復(fù)讀機(jī)。第三步復(fù)盤。每成功解決一個(gè)問題我會(huì)把這個(gè)問題、AI 給出的解決方案、我自己的理解一起寫進(jìn)筆記并給這個(gè) SQL 加上注釋說明它解決的是什么場(chǎng)景的問題。這樣的筆記積累到一定程度就相當(dāng)于有了一本自己的《SQL 答案書》下次遇到類似需求直接翻筆記就能找到思路。對(duì)了我用 AI 學(xué)習(xí)時(shí)有個(gè)小原則同一個(gè)問題至少換兩種問法去問對(duì)比不同答案。因?yàn)榇竽Ｐ团紶枙?huì)一本正經(jīng)地給出錯(cuò)誤建議多問幾次可以交叉驗(yàn)證也能幫自己發(fā)現(xiàn)理解上的漏洞。這個(gè)我后面會(huì)在講避坑的部分再細(xì)說。2. DDL語(yǔ)句庫(kù)和表的結(jié)構(gòu)設(shè)計(jì)才是基本功2.1 先搞清楚 CREATE DATABASE 背后的字符集邏輯日常開發(fā)中很多人建庫(kù)就用一行 CREATE DATABASE db_name其實(shí)這里面還藏著字符集和排序規(guī)則的選擇問題。數(shù)據(jù)庫(kù)的字符集決定了它能存放哪些字符類型的文本排序規(guī)則則影響字符串怎么比較和排序。比如 utf8mb4 和 utf8mb4_unicode_ci、utf8mb4_general_ci實(shí)際使用中經(jīng)常有人選錯(cuò)導(dǎo)致后續(xù)字段里的 emoji 存不進(jìn)去或者排序結(jié)果跟預(yù)期不一致。我在 AI 學(xué)習(xí)的提問里專門問過這個(gè)問題得到的解釋讓我印象很深MySQL 中的 utf8 只是 utf8mb3 的別名最大只有 3 個(gè)字節(jié)根本存不了 emoji 和部分冷門漢字所以從 8.0 開始官方推薦用 utf8mb4。排序規(guī)則里_unicode_ci 基于 Unicode 排序算法支持更多語(yǔ)言的精度_general_ci 更快但在某些特殊字符的比較上不那么嚴(yán)謹(jǐn)。如果你只是做中文項(xiàng)目?jī)烧卟顒e不大但為了保險(xiǎn)起見我建議直接用 utf8mb4 utf8mb4_unicode_ci。建庫(kù)的標(biāo)準(zhǔn)姿勢(shì)我建議寫成這樣CREATE DATABASE IF NOT EXISTS shop DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_unicode_ci;這里用 IF NOT EXISTS 避免重復(fù)執(zhí)行的報(bào)錯(cuò)顯式指定字符集和排序規(guī)則可以防止 MySQL 用了默認(rèn)配置之后在遷移環(huán)境時(shí)出現(xiàn)亂碼。很多教程只讓你寫庫(kù)名我覺得這是偷懶等到數(shù)據(jù)出了問題才后悔當(dāng)初沒多寫兩行。2.2 建表語(yǔ)句字段類型、約束與默認(rèn)值的一次說清建表是 DDL 的核心而一次建好表遠(yuǎn)比事后頻繁 ALTER 來得省心。字段類型的選擇直接決定存儲(chǔ)效率和查詢性能我在筆記里總結(jié)了幾個(gè)高頻原則整數(shù)用 INT 或 BIGINT別用 VARCHAR 存手機(jī)號(hào)金額用 DECIMAL(10,2) 而不是 FLOAT避免浮點(diǎn)誤差日期時(shí)間優(yōu)先用 DATETIMETIMESTAMP 有時(shí)區(qū)換算和 2038 年的坑長(zhǎng)文本用 TEXT但要注意它不能有默認(rèn)值狀態(tài)值優(yōu)先考慮 TINYINT可讀性靠代碼注釋補(bǔ)。除了類型約束也不能省。一張表通常要有主鍵約束保證每行能唯一標(biāo)識(shí)非空約束防止臟數(shù)據(jù)進(jìn)入唯一約束比如用戶登錄名、訂單編號(hào)這類業(yè)務(wù)上不允許重復(fù)的字段默認(rèn)值則能省去插入時(shí)反復(fù)傳相同值的麻煩。很多新手建表時(shí)只設(shè)置主鍵和自增其他全靠代碼把關(guān)結(jié)果上線沒多久就出現(xiàn)重復(fù)數(shù)據(jù)或者空記錄改起來非常痛苦。我讓 AI 幫我生成過一張用戶表的示例再結(jié)合我的修改最后沉淀下來的版本大致是這樣的CREATE TABLE user ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 主鍵, username VARCHAR(32) NOT NULL COMMENT 用戶名, email VARCHAR(128) NOT NULL COMMENT 郵箱, phone VARCHAR(20) DEFAULT NULL COMMENT 手機(jī)號(hào), status TINYINT NOT NULL DEFAULT 1 COMMENT 狀態(tài)1啟用 0禁用, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 創(chuàng)建時(shí)間, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新時(shí)間, PRIMARY KEY (id), UNIQUE KEY uk_username (username), UNIQUE KEY uk_email (email) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci COMMENT用戶表;注意 ENGINEInnoDB因?yàn)?InnoDB 支持事務(wù)和外鍵也是 8.0 的默認(rèn)引擎。create_time 和 update_time 用 DEFAULT CURRENT_TIMESTAMP 系列可以減少應(yīng)用層代碼的重復(fù)賦值。這些都是我在實(shí)際項(xiàng)目里踩過坑之后才學(xué)會(huì)加上的。2.3 讓AI幫我設(shè)計(jì)表結(jié)構(gòu)我是怎么問的很多人用 AI 提的是幫我設(shè)計(jì)用戶表結(jié)果 AI 給你生成一個(gè)有十幾個(gè)字段的大雜燴根本沒法用。這里的門道在于你要把表的使用場(chǎng)景和核心約束交代清楚。我實(shí)際的問法是我要設(shè)計(jì)一張用戶表用于一個(gè)電商后臺(tái)系統(tǒng)。用戶登錄用用戶名和密碼密碼存加密后的字符串用戶有手機(jī)號(hào)、郵箱、頭像地址需要記錄注冊(cè)時(shí)間和最后一次登錄時(shí)間用戶可以被管理員禁用。請(qǐng)給出建表 SQL并解釋每個(gè)字段類型為什么這樣選擇。這樣一問AI 給出的字段就基本符合需求理由也能幫你復(fù)習(xí)一波。拿到 AI 的答案之后我還會(huì)追問幾個(gè)問題這個(gè)表是否需要唯一索引手機(jī)號(hào)允許為空時(shí)怎么建唯一索引這種追問特別有價(jià)值因?yàn)?AI 會(huì)解釋 MySQL 中多個(gè) NULL 值在唯一索引里是允許的這在面試?yán)镆步?jīng)?？嫉?。通過這種方式我不僅拿到了建表語(yǔ)句還順帶搞懂了背后的約束機(jī)制。2.4 修改表結(jié)構(gòu)時(shí)最容易忽略的三個(gè)坑ALTER TABLE 在日常開發(fā)里用得非常頻繁常見操作包括增加字段、修改字段類型、刪除字段、添加索引。操作本身不難但有幾個(gè)坑我必須要提。第一個(gè)坑是修改字段類型時(shí)可能造成數(shù)據(jù)丟失。比如把 VARCHAR(50) 改成 VARCHAR(20)如果已有數(shù)據(jù)里有超過 20 個(gè)字符的值MySQL 在嚴(yán)格模式下會(huì)直接報(bào)錯(cuò)非嚴(yán)格模式下可能截?cái)鄶?shù)據(jù)。所以每次 ALTER 之前建議先用 SELECT MAX(LENGTH(field)) 這種語(yǔ)句確認(rèn)一下最長(zhǎng)的字段值有多長(zhǎng)。第二個(gè)坑是大表 ALTER 會(huì)鎖表。MySQL 8.0 之前 ALTER TABLE 很多操作會(huì)鎖住整個(gè)表在線 DDL 支持也有不少限制。如果你在一個(gè)幾千萬(wàn)行的表上直接加字段業(yè)務(wù)高峰期很可能直接卡死。常規(guī)做法是錯(cuò)峰執(zhí)行或者用 gh-ost、pt-online-schema-change 這類工具做在線變更。對(duì)于學(xué)習(xí)階段至少要知道這個(gè)風(fēng)險(xiǎn)存在別在線上環(huán)境隨便試。第三個(gè)坑是刪除字段和索引前先確認(rèn)引用關(guān)系。尤其是外鍵、視圖、存儲(chǔ)過程里可能引用了某個(gè)字段直接 DROP 掉會(huì)導(dǎo)致后續(xù)運(yùn)行到一半報(bào)錯(cuò)。我讓 AI 幫我檢查過這種問題它的答案往往是一張依賴關(guān)系梳理表格非常直觀?？傊慕Y(jié)構(gòu)不要一上來就 DROP先查一下有多少地方在用它。3. DML語(yǔ)句增刪改查的底層邏輯3.1 INSERT 的幾種姿勢(shì)選對(duì)能省一大截代碼DML 是 Data Manipulation Language也就是增刪改。INSERT 是最基礎(chǔ)的寫入操作但寫法不少。單條插入是最簡(jiǎn)單的形式這點(diǎn)不用多說需要注意的是字段列表最好顯式列出來不要省略因?yàn)橐坏┍斫Y(jié)構(gòu)變了省略字段列表的寫法很容易插錯(cuò)列。多條插入的方式我用的最多一條 SQL 同時(shí)插入多行性能比多條單行 insert 好不少尤其是應(yīng)用需要批量導(dǎo)入數(shù)據(jù)時(shí)INSERT INTO user (username, email, status) VALUES (alice, aliceexample.com, 1), (bob, bobexample.com, 1), (carol, carolexample.com, 0);還有一種比較高級(jí)的 INSERT INTO ... SELECT把一張表里查詢出來的結(jié)果直接插入另一張表比如把歸檔表的舊數(shù)據(jù)搬回主表或者做數(shù)據(jù)遷移、生成測(cè)試數(shù)據(jù)。這里要特別注意字段數(shù)量和類型對(duì)得上以及防止插入重復(fù)數(shù)據(jù)通常需要配合 DISTINCT 或 WHERE 條件來過濾。新手最容易在這里翻車明明只想插入部分?jǐn)?shù)據(jù)結(jié)果 SELECT 條件的唯一性沒控制好插了一堆重復(fù)行進(jìn)去最后只能靠唯一索引去兜底攔截。3.2 UPDATE 和 DELETE 的保命習(xí)慣WHERE 寫清楚再執(zhí)行說到 UPDATE 和 DELETE我必須先把這條保命規(guī)則放在最前面執(zhí)行這兩個(gè)語(yǔ)句之前先用同條件 SELECT 查一遍確認(rèn)影響的行數(shù)和目標(biāo)范圍符合預(yù)期再執(zhí)行 UPDATE 或 DELETE。特別是 DELETE刪了基本很難恢復(fù)除非你提前做了備份或者開啟了 binlog。有一個(gè)我印象很深的事故有同事執(zhí)行 UPDATE 語(yǔ)句時(shí)因?yàn)闂l件里少了一個(gè)引號(hào)沒寫對(duì)導(dǎo)致整個(gè)表的所有記錄都被改成了同一個(gè)值。當(dāng)時(shí)沒有任何防護(hù)措施只能從備份里恢復(fù)前后折騰了半個(gè)多小時(shí)。這件事之后我在自己的筆記里加了一條鐵律UPDATE 和 DELETE 的 WHERE 條件必須寫明確能加 LIMIT 就加上 LIMIT尤其是在手工維護(hù)數(shù)據(jù)的時(shí)候。LIMIT 是一個(gè)容易被忽視但很好用的安全閥。比如 DELETE FROM order WHERE status 3 LIMIT 100; 可以先刪掉 100 條檢查無誤后再繼續(xù)刪避免一次刪幾百萬(wàn)行把表鎖死或者誤刪所有數(shù)據(jù)。MySQL 的 DELETE 支持 LIMITUPDATE 也可以只要注意配合 ORDER BY 來確定刪除順序。3.3 事務(wù)與DML的關(guān)系為什么改數(shù)據(jù)容易翻車INSERT、UPDATE、DELETE 這幾個(gè)操作都跟事務(wù)緊密相關(guān)。事務(wù)能保證一批操作要么全部成功、要么全部回滾典型應(yīng)用是轉(zhuǎn)賬扣款和入賬必須作為一個(gè)整體提交不能只成功一半。MySQL 默認(rèn)情況下每條 DML 語(yǔ)句是自動(dòng)提交的也就是說執(zhí)行完立即生效。如果你想讓多條語(yǔ)句組成一個(gè)事務(wù)需要顯式開啟和控制提交START TRANSACTION; UPDATE account SET balance balance - 100 WHERE id 1; UPDATE account SET balance balance 100 WHERE id 2; COMMIT;如果在第二步執(zhí)行后發(fā)現(xiàn)數(shù)據(jù)有問題可以 ROLLBACK 回滾兩個(gè)操作都不會(huì)生效。在學(xué)習(xí)階段我特別推薦在事務(wù)里多試試 ROLLBACK這能讓你放心地實(shí)驗(yàn)各種 DML 語(yǔ)句而不用擔(dān)心把測(cè)試數(shù)據(jù)搞壞。等我慢慢理解了事務(wù)之后才發(fā)現(xiàn) DML 操作本質(zhì)上并不僅僅是單條 SQL 的執(zhí)行而是跟并發(fā)控制、隔離級(jí)別、日志機(jī)制綁定在一起的這也是為什么面試總愛把 DML 和事務(wù)放在一起問。3.4 用AI排查DML問題的實(shí)例一次更新卡很久的經(jīng)驗(yàn)我實(shí)際操作中遇到過一種非常典型的 DML 性能問題一條 UPDATE 語(yǔ)句執(zhí)行得特別慢明明只是改了十幾條數(shù)據(jù)卻卡了好幾秒。當(dāng)時(shí)我把 SQL 和表結(jié)構(gòu)丟給 AIAI 很快就給出了判斷方向大概率是更新涉及的字段根本沒有索引導(dǎo)致每次定位數(shù)據(jù)都需要全表掃描而且如果被更新的行數(shù)比較多還會(huì)產(chǎn)生大量行鎖和并發(fā)的 SELECT 發(fā)生鎖等待。順著這個(gè)思路我檢查了 WHERE 條件里的字段確實(shí)沒有索引。后來加上索引之后同樣的 UPDATE 從幾秒降到毫秒級(jí)。AI 在排查這類問題上的價(jià)值在于它能快速列出索引缺失、鎖等待、大事務(wù)、字段長(zhǎng)度截?cái)嗟葞追N可能性并提供對(duì)應(yīng)的檢查 SQL。比如 SHOW PROCESSLIST 看鎖等待、information_schema.innodb_trx 查未提交事務(wù)這些都是我實(shí)際用過的排查手段。不過我也提醒一句AI 能幫你排查但最終執(zhí)行前你必須自己在測(cè)試環(huán)境復(fù)現(xiàn)一遍。尤其是線上操作寧可多花五分鐘確認(rèn)不要省這一步直接在生產(chǎn)庫(kù)上跑。4. DQL語(yǔ)句查詢的世界觀與執(zhí)行順序4.1 理解了邏輯執(zhí)行順序復(fù)雜的SELECT也不再難讀DQL 就是 Data Query Language核心是 SELECT 查詢。很多人寫查詢是從需求往代碼上硬套能跑就行一旦遇到嵌套子查詢、多表連接就覺得頭大。我覺得最有效的突破點(diǎn)是先理解 SELECT 語(yǔ)句的邏輯執(zhí)行順序而不是寫出來的順序。SELECT 語(yǔ)句的書寫順序是 SELECT、FROM、WHERE、GROUP BY、HAVING、ORDER BY、LIMIT但數(shù)據(jù)庫(kù)引擎邏輯上大致按這樣的順序處理先 FROM 確定數(shù)據(jù)源再 WHERE 過濾行接著 GROUP BY 分組然后 HAVING 過濾分組再 SELECT 投影出需要的列之后 ORDER BY 排序最后 LIMIT 限制返回行數(shù)。這個(gè)順序非常關(guān)鍵比如你問為什么 WHERE 里不能使用 SELECT 中定義的別名答案就是 WHERE 比 SELECT 先執(zhí)行此時(shí)別名還沒生成自然用不了。AI 幫我把這個(gè)執(zhí)行順序編成了一個(gè)實(shí)際例子有個(gè)訂單表只統(tǒng)計(jì)狀態(tài)為已支付的訂單按照用戶分組統(tǒng)計(jì)每個(gè)用戶的訂單數(shù)并且只顯示訂單數(shù)大于等于 3 的用戶最后按照訂單數(shù)降序輸出前 10 名。對(duì)應(yīng)的完整 SQL 是這樣的SELECT user_id, COUNT(*) AS order_cnt FROM orders WHERE status 1 GROUP BY user_id HAVING COUNT(*) 3 ORDER BY order_cnt DESC LIMIT 10;我建議大家拿到任何一條復(fù)雜的 SELECT都先按這個(gè)順序在心里過一遍再拆解每一步做的是什么。方法熟練之后N 條 JOIN 的 SQL 也只是多了一些數(shù)據(jù)源罷了。4.2 WHERE條件里的那些坑NULL、LIKE、IN和索引WHERE 是最常用的過濾條件但坑也最多。第一個(gè)坑是 NULL 參與比較。任何普通比較運(yùn)算符遇到 NULL結(jié)果都是未知在 WHERE 判定里等價(jià)于不成立所以查某個(gè)字段為空的記錄要寫成 IS NULL不能寫 NULL查不為空的要寫 IS NOT NULL。這個(gè)錯(cuò)誤特別隱蔽因?yàn)檎Z(yǔ)句不會(huì)報(bào)錯(cuò)只是查詢結(jié)果不符合預(yù)期。第二個(gè)坑是 LIKE 匹配和索引失效。前導(dǎo)模糊的寫法比如 LIKE %keyword%因?yàn)闊o法從字符串開頭定位通常沒法走索引數(shù)據(jù)量大時(shí)查詢會(huì)很慢。所以我處理搜索類需求時(shí)會(huì)盡量避免用前導(dǎo)通配符或者在 AI 輔助下改用全文索引、外部搜索引擎等方案。第三個(gè)坑是 IN 和 NOT IN 里的坑。IN 比 OR 更容易讀但列表過多時(shí)會(huì)影響性能NOT IN 如果子查詢結(jié)果中包含 NULL整個(gè)結(jié)果可能為空因?yàn)?NOT IN 對(duì)這種 NULL 的判斷同樣返回未知。對(duì)應(yīng)地我習(xí)慣用 NOT EXISTS 來替代部分 NOT IN 場(chǎng)景語(yǔ)義更清楚也不容易出錯(cuò)。4.3 聚合與分組COUNT 里數(shù)不清的細(xì)節(jié)聚合函數(shù)讓 SQL 從普通查詢變成統(tǒng)計(jì)分析但用起來有不少細(xì)節(jié)。以 COUNT 為例COUNT() 統(tǒng)計(jì)的是行數(shù)COUNT(column) 統(tǒng)計(jì)的是該字段非 NULL 的值的個(gè)數(shù)兩者在字段含 NULL 時(shí)結(jié)果不同。判斷某張表有多少記錄老老實(shí)實(shí)用 COUNT()判斷某個(gè)字段有多少非空值用 COUNT(column)。SUM 和 AVG 也有類似的 NULL 陷阱SUM(column) 會(huì)忽略 NULL 行AVG 也會(huì)基于非 NULL 行計(jì)算。如果一列全是 NULLSUM 返回 NULL 而不是 0。處理時(shí)常用 IFNULL 或 COALESCE 把結(jié)果轉(zhuǎn)成 0避免應(yīng)用層拿到 NULL 之后報(bào)空指針之類的錯(cuò)誤。GROUP BY 的爭(zhēng)議點(diǎn)主要來自 ONLY_FULL_GROUP_BY 模式。MySQL 5.7 之后默認(rèn)開啟了這個(gè)模式SELECT 中出現(xiàn)的非聚合列必須出現(xiàn)在 GROUP BY 子句中否則直接報(bào)錯(cuò)。比如 SELECT user_id, order_id, COUNT(*) FROM orders GROUP BY user_id; 在 5.7 下就報(bào)錯(cuò)因?yàn)?order_id 不在分組里也不在聚合函數(shù)里。這種設(shè)計(jì)是為了防止數(shù)據(jù)歧義但很多從舊版本遷移過來的人會(huì)很不習(xí)慣。我在學(xué)習(xí)時(shí)會(huì)故意在測(cè)試庫(kù)里關(guān)閉和開啟這個(gè)模式觀察差異理解為什么官方要這么改。4.4 多表連接JOIN 用不對(duì)結(jié)果多一行都別奇怪多表連接是很多人的分水嶺。INNER JOIN 只返回兩邊都能匹配上的行LEFT JOIN 返回左表所有行右表匹配不上的地方補(bǔ) NULLRIGHT JOIN 是反過來。實(shí)際開發(fā)中 LEFT JOIN 用得最多意思是以某張表為主體把關(guān)聯(lián)表的數(shù)據(jù)補(bǔ)進(jìn)來。這里我要強(qiáng)調(diào)一個(gè)常見的誤區(qū)LEFT JOIN 的結(jié)果行數(shù)不是一定等于左表行數(shù)。如果右表在關(guān)聯(lián)字段上有重復(fù)數(shù)據(jù)左表的同一行會(huì)被放大成多行結(jié)果自然就膨脹了。比如左表是訂單表右表是訂單日志表一個(gè)訂單對(duì)應(yīng)多條日志直接 LEFT JOIN 就會(huì)發(fā)現(xiàn)訂單被重復(fù)計(jì)算了很多次。這個(gè)坑我在 AI 生成的案例里見過很多次AI 生成 SQL 時(shí)并不會(huì)自動(dòng)幫你去重它默認(rèn)假設(shè)你了解數(shù)據(jù)模型。所以每寫完一條 JOIN都要檢查一下結(jié)果行數(shù)是否合理。在多個(gè) JOIN 的復(fù)雜查詢里我還建議按照?qǐng)?zhí)行順序給每個(gè)表字段加簡(jiǎn)寫前綴比如 o.user_id、l.order_id避免同名沖突也讓執(zhí)行計(jì)劃更容易讀。AI 生成的代碼如果帶了這種前綴通常是比較靠譜的答案。4.5 排序與分頁(yè)LIMIT 百萬(wàn)級(jí)分頁(yè)為什么慢排序和分頁(yè)是查詢輸出的最后兩道工序。ORDER BY 支持多字段排序字段在前表示優(yōu)先級(jí)高方向可以混用比如 ORDER BY status ASC, create_time DESC。排序通常是內(nèi)存或磁盤上的排序操作數(shù)據(jù)量大、沒有索引支撐時(shí)性能會(huì)下降A(chǔ)LTER 加個(gè)覆蓋索引能明顯改善。分頁(yè) LIMIT offset, rows 用起來很簡(jiǎn)單但隱患藏在 offset 很大時(shí)。比如 LIMIT 100000, 20MySQL 必須先找到前 100000 行然后丟棄再返回后面的 20 行這個(gè)找到的過程掃描量很大翻到后面的頁(yè)面就會(huì)越來越慢。我對(duì)這個(gè)問題的解法主要有兩種一種是用上一頁(yè)最后一個(gè) ID做條件比如 WHERE id last_id ORDER BY id LIMIT 20只適合按主鍵順序翻頁(yè)另一種是把大 OFFSET 換成子查詢先取出主鍵集合再用主鍵 JOIN 回原表取數(shù)據(jù)。AI 在優(yōu)化這類分頁(yè)時(shí)經(jīng)常給出第一種方案因?yàn)樗詈?jiǎn)單但具體適用與否還要看你的排序字段是否支持這種游標(biāo)式分頁(yè)。5. AI輔助學(xué)習(xí)中的提問技巧與避坑5.1 一個(gè)可復(fù)用的提問模板給場(chǎng)景、給表結(jié)構(gòu)、要解釋我試過不少提問方式最有效的還是結(jié)構(gòu)化的描述。完整模板大致是四件套背景說明、表結(jié)構(gòu)或字段清單、具體需求、期望的輸出形式。舉個(gè)例子我如果要 AI 幫我查用戶留存我會(huì)這么問有一張用戶登錄記錄表 login_log字段包含 id、user_id、login_date、login_time請(qǐng)統(tǒng)計(jì) 3 月 1 日到 3 月 7 日之間每天活躍用戶數(shù)并與前一天相比計(jì)算新增用戶和流失用戶給出 SQL 和步驟解釋。這樣 AI 給出的答案不僅包含 SQL還有邏輯拆解。另外一個(gè)技巧是讓 AI 做選擇題而不是簡(jiǎn)答題。比如我想知道某種寫法好不好可以問下面兩種寫法在數(shù)據(jù)量和索引上有什么差異哪種更推薦為什么AI 會(huì)給出對(duì)比和理由幫我建立判斷標(biāo)準(zhǔn)。這種決策式提問對(duì)形成自己的 SQL 審美很管用。5.2 AI生成SQL的三個(gè)天然局限知道才能不翻車AI 雖然有本事但生成 SQL 這件事上存在幾個(gè)明顯局限。第一個(gè)是業(yè)務(wù)語(yǔ)義缺失。比如刪除這個(gè)用戶在業(yè)務(wù)上可能不是真的 DELETE而是把 status 字段置為禁用如果只按字面意思讓 AI 生成 DELETE 語(yǔ)句它在語(yǔ)法上沒問題但在業(yè)務(wù)上可能是事故。所以必須把業(yè)務(wù)規(guī)則寫進(jìn)問題里比如邏輯刪除而不是物理刪除。第二個(gè)是不知道索引情況。AI 不會(huì)自動(dòng)知道你表上有哪些索引、數(shù)據(jù)分布怎么樣也無法告訴你它生成的 SQL 在你的表上到底能不能走索引。所以 AI 給出的查詢語(yǔ)句到了真實(shí)環(huán)境可能很慢。我的習(xí)慣是在 AI 生成后自己在表上建好測(cè)試數(shù)據(jù)跑 EXPLAIN以執(zhí)行計(jì)劃為準(zhǔn)。第三個(gè)是版本兼容性。AI 的訓(xùn)練數(shù)據(jù)里往往混雜著各個(gè)版本的寫法有時(shí)候給你一個(gè) MySQL 5.7 能跑、8.0 已廢棄的語(yǔ)法或者反過來。比如 MySQL 8.0 里 WITH 子句、窗口函數(shù)都很好用但這不代表你的線上環(huán)境版本支持。所以提問時(shí)最好注明版本號(hào)比如請(qǐng)基于 MySQL 8.0 環(huán)境給出方案。5.3 我踩過的AI學(xué)習(xí)坑別把AI當(dāng)作標(biāo)準(zhǔn)答案我踩過的最典型的坑是 AI 一本正經(jīng)地編造出一個(gè)不存在的函數(shù)。當(dāng)時(shí)我問它怎么在 MySQL 里做字符串聚合它直接給出了 STRAGG 這種函數(shù)我一看不對(duì)在真實(shí)環(huán)境里執(zhí)行直接報(bào)錯(cuò)。后來我總結(jié)出一個(gè)防御性習(xí)慣凡是 AI 給的函數(shù)名、語(yǔ)法關(guān)鍵字我會(huì)先在官方文檔或本地環(huán)境驗(yàn)證一遍再往筆記里放。另一個(gè)坑是 AI 對(duì)業(yè)務(wù)問題的過度簡(jiǎn)化。有次我讓它分析訂單金額異常它給出的查詢只判斷了金額小于 0 的訂單但實(shí)際上業(yè)務(wù)里還有金額為 0 的異常單、退款未同步的記錄等。AI 只能根據(jù)你給的信息給出常規(guī)判斷它不會(huì)主動(dòng)想到你的業(yè)務(wù)中還藏著哪些特殊規(guī)則。因此我一直把 AI 當(dāng)作助理而不是專家用它加速學(xué)習(xí)、提供思路但最終的決策判斷和結(jié)果校驗(yàn)必須落在自己身上。6. 實(shí)戰(zhàn)案例結(jié)合AI從零完成一個(gè)簡(jiǎn)單的訂單統(tǒng)計(jì)需求6.1 需求與表結(jié)構(gòu)設(shè)計(jì)從需求到DDL的一步步推演為了把前面的知識(shí)點(diǎn)串起來我用一個(gè)完整案例演示一遍一個(gè)包含用戶、商品、訂單三張表的電商庫(kù)里需要統(tǒng)計(jì)出每個(gè)用戶的訂單總金額和訂單數(shù)量并且按總金額降序只看最近30天有訂單的用戶取前10名。先設(shè)計(jì)三張表。user 表沿用前面設(shè)計(jì)商品表 product 需要 id、商品名稱、價(jià)格、庫(kù)存訂單表 order 需要訂單號(hào)、用戶ID、下單時(shí)間、狀態(tài)、總金額。為了讓演示更直觀我把狀態(tài)字段用 TINYINT金額用 DECIMAL。建表之前我先讓 AI 基于用戶表、商品表、訂單表三張表做訂單統(tǒng)計(jì)給出一版設(shè)計(jì)再根據(jù)我的需求調(diào)整字段。實(shí)際操作中這一步就等于是把第 2 章的 DDL 知識(shí)又復(fù)習(xí)了一遍。我用簡(jiǎn)化后的建表 SQL保持核心約束CREATE TABLE user ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, username VARCHAR(32) NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE product ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, name VARCHAR(64) NOT NULL, price DECIMAL(10,2) NOT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE orders ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, user_id BIGINT UNSIGNED NOT NULL, product_id BIGINT UNSIGNED NOT NULL, amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT 1-已支付 0-未支付, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_create_time (create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;可以看到我在訂單表的 user_id 和 create_time 上建了索引因?yàn)楹罄m(xù)統(tǒng)計(jì)大概率會(huì)按這兩個(gè)條件過濾和分組。這個(gè)預(yù)判能力其實(shí)就是學(xué)習(xí)中積累的經(jīng)驗(yàn)。6.2 初始化與更新測(cè)試數(shù)據(jù)DML部分的實(shí)際應(yīng)用表建好之后得先往里塞數(shù)據(jù)才能測(cè)試查詢。我用 INSERT 多行插入的方式初始化了一批用戶和商品然后用 INSERT INTO ... SELECT 的方式給訂單表生成了一批隨機(jī)測(cè)試訂單這樣能直觀感受一下 DML 里的批量操作。為了模擬真實(shí)業(yè)務(wù)我還跑了幾個(gè) UPDATE 和 DELETE 操作。比如把某個(gè)用戶名字段統(tǒng)一格式做更新或者刪除一批訂單狀態(tài)為 0 的測(cè)試數(shù)據(jù)。執(zhí)行 DELETE 前我先 SELECT COUNT(*) 確認(rèn)要?jiǎng)h除的行數(shù)再執(zhí)行 DELETE。這種先查后刪的習(xí)慣多虧了第 3 章的教訓(xùn)現(xiàn)在已經(jīng)是肌肉記憶了。這個(gè)過程中我還故意做了一次錯(cuò)誤的 UPDATE 演示把 orders 表里的 status 字段全部改成 0然后看到全表更新 120 行再用事務(wù)回滾找補(bǔ)。通過親手操作一次翻車現(xiàn)場(chǎng)記憶遠(yuǎn)比看文檔深刻。6.3 統(tǒng)計(jì)需求的DQL實(shí)現(xiàn)從單表到多表接著進(jìn)入核心查詢。訂單表里已經(jīng)有 user_id但要展示用戶名需要 JOIN 用戶表。問題是要不要 JOIN 商品表需求里只要用戶維度的匯總不需要商品名稱所以我只 JOIN 了 user 表。要是順手 JOIN 了 product 表很可能因?yàn)橐粋€(gè)用戶購(gòu)買多個(gè)商品而出現(xiàn)訂單行數(shù)膨脹統(tǒng)計(jì)金額就要翻車。這一步很好地驗(yàn)證了第 4 章里JOIN 會(huì)放大行數(shù)的判斷。最終查詢版本SELECT u.username, COUNT(o.id) AS order_cnt, SUM(o.amount) AS total_amount FROM orders o INNER JOIN user u ON u.id o.user_id WHERE o.status 1 AND o.create_time DATE_SUB(NOW(), INTERVAL 30 DAY) GROUP BY u.id, u.username HAVING COUNT(o.id) 1 ORDER BY total_amount DESC LIMIT 10;稍微解釋一下幾個(gè)細(xì)節(jié)。COUNT(o.id) 統(tǒng)計(jì)訂單數(shù)比 COUNT(*) 更明確因?yàn)?JOIN 后主表行數(shù)可能被放大用主鍵列計(jì)數(shù)能消除部分歧義。GROUP BY u.id, u.username 符合 ONLY_FULL_GROUP_BY 要求u.id 和 u.username 都在分組里。HAVING 在分組后過濾保證只是有訂單的用戶。整個(gè) SQL 我是在 AI 輔助下寫的自己又手動(dòng)加了 JOIN 理由和字段注釋等于上了一節(jié)綜合復(fù)習(xí)課。6.4 用EXPLAIN檢查執(zhí)行計(jì)劃驗(yàn)證AI生成SQL的可用性SQL 寫完不能算完必須用 EXPLAIN 看執(zhí)行計(jì)劃。我習(xí)慣在語(yǔ)句前面加 EXPLAIN觀察 key 列是否用上了索引rows 列估算的掃描行數(shù)是否合理。比如上面這條統(tǒng)計(jì)語(yǔ)句如果 EXPLAIN 顯示 orders 表在 type 列上是 ALL說明它在做全表掃描在有 30 天過濾條件下這就很可能存在問題。實(shí)際測(cè)試中因?yàn)槲以?create_time 上建了索引并且查詢條件里用 create_time 一個(gè)計(jì)算出來的日期MySQL 能走范圍查詢效果很好。如果發(fā)現(xiàn)要用到 filesort 或者臨時(shí)表就要考慮是不是加了太多 DISTINCT、ORDER BY 或者 GROUP BY 字段。AI 會(huì)在你給它 EXPLAIN 結(jié)果后幫你分析哪里有問題這也是一個(gè)很好的學(xué)習(xí)閉環(huán)。我在筆記里給這個(gè)案例總結(jié)了三個(gè)檢查點(diǎn)JOIN 字段有沒有索引、WHERE 條件能不能用上索引、排序和分組是否觸發(fā)了臨時(shí)表。任何一條查詢上線前我都會(huì)按這三個(gè)點(diǎn)過一遍基本不會(huì)出大問題。7. 沉淀筆記把自己的學(xué)習(xí)成果整理成一套SQL手冊(cè)7.1 筆記結(jié)構(gòu)怎么搭才能既方便復(fù)習(xí)又方便查閱我整理 MySQL 筆記不是簡(jiǎn)單地把 SQL 語(yǔ)句抄下來而是要形成問題—方案—理由—注意點(diǎn)的結(jié)構(gòu)。比如一個(gè)知識(shí)點(diǎn)我通常會(huì)分四欄記錄這個(gè)知識(shí)點(diǎn)解決什么問題、標(biāo)準(zhǔn)寫法、為什么這樣寫、有哪些邊界情況。用這種格式記錄后續(xù)復(fù)習(xí)時(shí)效率非常高因?yàn)槊總€(gè)條目都對(duì)應(yīng)著一個(gè)實(shí)際使用場(chǎng)景。我的筆記目錄大致是基礎(chǔ)概念、DDL 建表與約束、DML 增刪改與事務(wù)、DQL 查詢與執(zhí)行計(jì)劃、索引優(yōu)化、常見報(bào)錯(cuò)速查。每個(gè)大類下面按知識(shí)點(diǎn)拆成小條目。這樣不管是面試前突擊還是工作中查問題幾分鐘就能定位到對(duì)應(yīng)內(nèi)容。7.2 如何用AI把散裝筆記變成體系化文檔筆記寫多了之后我會(huì)定期把散裝記錄交給 AI 做一次合并和糾偏。做法是把我記的若干條筆記片段丟給 AI請(qǐng)它按 DDL/DML/DQL 的分類重新組織成連貫的大綱并檢查是否存在矛盾或過時(shí)的信息。這個(gè)過程不能全自動(dòng)AI 整理完的版本必須自己再過一遍尤其是版本相關(guān)的說法比如某個(gè)參數(shù)在 MySQL 5.7 和 8.0 的默認(rèn)值差異一定要單獨(dú)核實(shí)。另外一個(gè) AI 的好用法是生成練習(xí)題。我會(huì)把已學(xué)的知識(shí)點(diǎn)匯總后讓 AI 出 10 道 SQL 練習(xí)題覆蓋建表、插入、更新、查詢、聚合、連接、分頁(yè)然后自己做一遍再讓 AI 批改。這種AI 出題 人工做題 AI 批改的模式比我一個(gè)人悶頭寫筆記有趣得多也更容易發(fā)現(xiàn)自己遺漏的知識(shí)點(diǎn)。7.3 后續(xù)還能往哪些方向擴(kuò)展DDL、DML、DQL 是數(shù)據(jù)庫(kù)學(xué)習(xí)的地基接下來值得擴(kuò)展的方向還有很多。比如事務(wù)隔離級(jí)別和 MVCC這是理解并發(fā)更新的關(guān)鍵索引優(yōu)化和 EXPLAIN 的深度分析能幫你把查詢性能調(diào)優(yōu)這門手藝練扎實(shí)存儲(chǔ)過程和觸發(fā)器雖然日常用得少但在批量維護(hù)場(chǎng)景里很實(shí)用還有備份恢復(fù)、主從復(fù)制這些運(yùn)維層面的內(nèi)容到了中型項(xiàng)目基本繞不開。如果工作里用到大數(shù)據(jù)常見的還有 Hive 里的 DDL 和 DML 操作和 MySQL 有相似之處但分區(qū)、分桶、動(dòng)態(tài)分區(qū)這些概念又完全不一樣。用 AI 輔助學(xué)習(xí)時(shí)這種跨數(shù)據(jù)庫(kù)的對(duì)比問法也特別好用比如問MySQL 和 Hive 的 GROUP BY 在分布式中有什么區(qū)別。不過這些都是后話先把 MySQL 的基礎(chǔ)打牢后面學(xué)任何 SQL 系的東西都會(huì)輕松很多。說回我自己用了大半天的 AI 輔助學(xué)習(xí)最大的感受不是AI 真方便而是學(xué)習(xí)方式真的被改變了以前是怕寫錯(cuò)不敢寫現(xiàn)在是敢寫敢問反正有 AI 可以幫我兜底分析。但我始終記得那個(gè) STRAGG 函數(shù)的教訓(xùn)AI 可以當(dāng)陪練、當(dāng)搜索引擎、當(dāng)出題老師唯獨(dú)不能當(dāng)唯一的知識(shí)來源。把 AI 給出的 SQL 拿到真實(shí)環(huán)境跑一遍、看看執(zhí)行計(jì)劃、親手造一次事故再回滾這些動(dòng)作才是真正把知識(shí)記進(jìn)腦子里的關(guān)鍵一步。希望這篇筆記能給你一些參照。如果你也是剛開始學(xué) MySQL我的建議很簡(jiǎn)單先用 AI 幫你把 DDL、DML、DQL 三類語(yǔ)句的骨架搭起來然后挑一個(gè)自己手頭的小需求從建表到查詢完整做一遍最后把整個(gè)過程沉淀成筆記。按這條路徑走下來你的 SQL 基礎(chǔ)會(huì)比單純看教程要扎實(shí)很多。