簡介這是一份面向互聯(lián)網(wǎng)行業(yè)求職者與數(shù)據(jù)庫初學(xué)者的SQL筆試面試專項(xiàng)訓(xùn)練資料聚焦關(guān)系型數(shù)據(jù)庫核心查詢能力提升覆蓋聚合統(tǒng)計(jì)、多表連接、子查詢、排序分頁等高頻考點(diǎn)。資源為單個(gè)PDF文件1.38MB內(nèi)容完整呈現(xiàn)28道經(jīng)典SQL題目及規(guī)范解答包括部門平均工資計(jì)算、最小值替代方案、客戶收入?yún)R總、最高分記錄提取、課程選修統(tǒng)計(jì)、部門薪資分析等典型場(chǎng)景每題均提供多種寫法并標(biāo)注關(guān)鍵語法要點(diǎn)。已有190人下載學(xué)習(xí)適合正在準(zhǔn)備技術(shù)崗筆試、夯實(shí)SQL實(shí)戰(zhàn)能力或查漏補(bǔ)缺的開發(fā)者。資料結(jié)構(gòu)清晰答案附帶執(zhí)行邏輯說明便于對(duì)照理解底層原理與書寫規(guī)范是快速提升SQL手寫能力的實(shí)用備考素材。1. 這不是“題庫搬運(yùn)”而是用 SQL 面試題反向錘煉工程級(jí)數(shù)據(jù)庫思維為什么90%的候選人栽在「增刪改查」的邊界上你手里的這份《SQL數(shù)據(jù)庫經(jīng)典編輯面試題修改筆試題有規(guī)范標(biāo)準(zhǔn)答案.docx.pdf》表面看是一份帶答案的PDF題集但真正值錢的是它背后隱含的工業(yè)級(jí)SQL能力標(biāo)尺——不是考你會(huì)不會(huì)寫SELECT * FROM users而是考你在真實(shí)業(yè)務(wù)場(chǎng)景里能不能用一條語句安全、可讀、可維護(hù)地解決一個(gè)有約束、有并發(fā)、有數(shù)據(jù)質(zhì)量要求的問題。比如“把2023年Q3訂單金額超5萬的客戶按城市分組取每組最新下單的3個(gè)用戶排除已注銷賬戶且結(jié)果必須保證事務(wù)一致性”。這種題GROUP BYLIMIT直接翻車ROW_NUMBER()用錯(cuò)窗口范圍會(huì)漏數(shù)據(jù)LEFT JOIN沒加IS NOT NULL判斷會(huì)引入臟關(guān)聯(lián)……而標(biāo)準(zhǔn)答案里那幾行帶注釋的SQL其實(shí)是把事務(wù)隔離級(jí)別選擇、索引覆蓋策略、NULL安全處理、執(zhí)行計(jì)劃預(yù)判全壓縮進(jìn)了一次查詢。它適合三類人剛過校招筆試但總卡在終面實(shí)操環(huán)節(jié)的應(yīng)屆生寫了五年CRUD但一碰復(fù)雜報(bào)表就調(diào)半天性能的中級(jí)開發(fā)還有正在搭建內(nèi)部SQL編碼規(guī)范的技術(shù)負(fù)責(zé)人——因?yàn)檫@份題集的“標(biāo)準(zhǔn)答案”本質(zhì)是把MySQL 8.0、PostgreSQL 14、SQL Server 2022的語法兼容性、優(yōu)化器行為、權(quán)限模型全映射到了具體題目里。別急著背答案先搞懂為什么這道題必須用WITH RECURSIVE而不是嵌套子查詢?yōu)槭裁碪PDATE ... FROM在PostgreSQL里合法在SQL Server里要改寫成UPDATE ... SET ... FROM ...這才是它能讓你少踩半年坑的核心價(jià)值。2. 從PDF題集到可驗(yàn)證環(huán)境用Docker快速搭起多版本SQL引擎沙箱拿到這份PDF第一反應(yīng)不該是打開Word劃重點(diǎn)而是立刻建一個(gè)能跑通所有題目的最小驗(yàn)證環(huán)境。原因很簡單同一道題“標(biāo)準(zhǔn)答案”在MySQL 5.7和MySQL 8.0下可能因ONLY_FULL_GROUP_BY默認(rèn)開關(guān)不同而報(bào)錯(cuò)在SQL Server里用TOP 3在PostgreSQL里就得用LIMIT 3加ORDER BY顯式聲明更別說JSON_EXTRACT函數(shù)在MariaDB 10.6才支持舊版只能靠正則硬啃。所以我們不裝本地?cái)?shù)據(jù)庫直接用Docker拉起三個(gè)容器各自暴露標(biāo)準(zhǔn)端口用統(tǒng)一客戶端連——這才是現(xiàn)代SQL工程師的起手式。2.1 三引擎并行沙箱MySQL 8.0 / PostgreSQL 14 / SQL Server 2022# 啟動(dòng)MySQL 8.0啟用ANSI模式貼近生產(chǎn) docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDpass123 \ -e MYSQL_DATABASEtestdb \ -v $(pwd)/mysql-init:/docker-entrypoint-initdb.d \ -d mysql:8.0 --sql-modeSTRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION # 啟動(dòng)PostgreSQL 14開pg_stat_statements監(jiān)控慢查詢 docker run -d \ --name pg14 \ -p 5432:5432 \ -e POSTGRES_PASSWORDpass123 \ -e POSTGRES_DBtestdb \ -v $(pwd)/pg-init:/docker-entrypoint-initdb.d \ -d postgres:14 -c shared_preload_librariespg_stat_statements -c pg_stat_statements.max1000 # 啟動(dòng)SQL Server 2022注意需接受EULA docker run -d \ --name mssql22 \ -e ACCEPT_EULAY \ -e MSSQL_SA_PASSWORDPassw0rd123! \ -p 1433:1433 \ -d mcr.microsoft.com/mssql/server:2022-latest提示mysql-init和pg-init目錄下放初始化SQL腳本如建表、插測(cè)試數(shù)據(jù)確保每次重啟容器后數(shù)據(jù)一致。SQL Server不支持掛載SQL腳本自動(dòng)執(zhí)行需用sqlcmd手動(dòng)導(dǎo)入稍后章節(jié)詳述。2.2 統(tǒng)一客戶端接入用DBeaver連接三引擎并做語法校驗(yàn)DBeaver是唯一能同時(shí)連通這三者的免費(fèi)GUI工具比DataGrip輕量比Navicat開源。關(guān)鍵配置點(diǎn)有三個(gè)MySQL連接驅(qū)動(dòng)選MySQL 8 (Connector/J)URL加參數(shù)?useSSLfalseserverTimezoneAsia/Shanghai否則時(shí)區(qū)錯(cuò)亂導(dǎo)致NOW()返回UTC時(shí)間PostgreSQL連接在“Driver Properties”里勾選Application Name填interview-test方便后續(xù)查pg_stat_activity定位慢查詢來源SQL Server連接協(xié)議必須選Microsoft Driver (SQLServer)不能選jTDS已廢棄端口填1433Authentication選SQL Server Authentication用戶名sa密碼即啟動(dòng)時(shí)設(shè)的Passw0rd123!。連通后右鍵連接→“SQL Editor”粘貼PDF里任意一道題的標(biāo)準(zhǔn)答案點(diǎn)擊“Execute SQL Statement”CtrlEnter。DBeaver會(huì)自動(dòng)識(shí)別當(dāng)前連接的數(shù)據(jù)庫類型高亮語法錯(cuò)誤——比如在MySQL里誤用TOP 3或在PostgreSQL里漏寫AS別名它會(huì)實(shí)時(shí)報(bào)紅。這是檢驗(yàn)“標(biāo)準(zhǔn)答案”是否真適配目標(biāo)環(huán)境的第一道篩子。2.3 測(cè)試數(shù)據(jù)生成用Python腳本批量造符合題干約束的臟數(shù)據(jù)PDF里常見題干如“統(tǒng)計(jì)每個(gè)部門薪資前3的員工排除試用期未轉(zhuǎn)正者”。如果只用INSERT INTO emp VALUES(...)手動(dòng)插10條數(shù)據(jù)根本測(cè)不出RANK()和DENSE_RANK()的區(qū)別也看不出WHERE status正式和WHERE status試用在NULL值上的語義差異。必須用腳本生成千級(jí)數(shù)據(jù)并注入典型臟數(shù)據(jù)# gen_test_data.py import random from datetime import datetime, timedelta departments [研發(fā), 測(cè)試, 產(chǎn)品, 運(yùn)營, HR] statuses [正式, 試用, 離職, None] # 注意None模擬NULL names [f張{chr(19968random.randint(0,100))} for _ in range(200)] with open(init_data.sql, w, encodingutf-8) as f: f.write(TRUNCATE TABLE employees;\n) for i in range(1000): dept random.choice(departments) status random.choice(statuses) salary random.randint(8000, 50000) if status 正式 else random.randint(4000, 12000) # 人為制造10%的NULL入職日期觸發(fā)DATE函數(shù)報(bào)錯(cuò) hire_date (datetime.now() - timedelta(daysrandom.randint(0, 3650))).strftime(%Y-%m-%d) if random.random() 0.1 else NULL f.write(fINSERT INTO employees VALUES ({i1}, {random.choice(names)}, {dept}, {salary}, {status}, {hire_date});\n)運(yùn)行后得到init_data.sql在DBeaver里執(zhí)行即可。重點(diǎn)在于status字段混入NULLhire_date字段混入NULL薪資分布按狀態(tài)分層——這樣一道“取各部門薪資Top3”的題才能暴露出ORDER BY salary DESC LIMIT 3錯(cuò)漏掉同薪并列、RANK() OVER(PARTITION BY dept ORDER BY salary DESC)對(duì)處理并列的本質(zhì)區(qū)別。沒有這種數(shù)據(jù)所謂“標(biāo)準(zhǔn)答案”只是紙上談兵。3. 解析標(biāo)準(zhǔn)答案的隱藏契約為什么同一道題在不同引擎里寫法必須變PDF里標(biāo)著“標(biāo)準(zhǔn)答案”的SQL絕不是放之四海皆準(zhǔn)的模板。它背后綁定了明確的引擎版本、SQL模式、事務(wù)隔離級(jí)別、甚至字符集。比如一道經(jīng)典題“查詢每個(gè)用戶最近3次登錄記錄”。在MySQL 8.0中可用ROW_NUMBER()但在MySQL 5.7里必須用變量模擬在PostgreSQL里DISTINCT ON是更優(yōu)解在SQL Server里TOP配合APPLY才是官方推薦。不看清這些契約直接抄答案輕則報(bào)錯(cuò)重則返回錯(cuò)誤結(jié)果。3.1 MySQL 8.0窗口函數(shù)是底線但ONLY_FULL_GROUP_BY是隱形地雷PDF中某題答案為SELECT user_id, login_time FROM ( SELECT user_id, login_time, ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY login_time DESC) rn FROM login_log ) t WHERE rn 3;這在MySQL 8.0默認(rèn)配置下能跑但如果你的生產(chǎn)庫開了ONLY_FULL_GROUP_BY強(qiáng)烈建議開啟而題干表結(jié)構(gòu)沒給login_log主鍵或唯一索引執(zhí)行時(shí)會(huì)報(bào)錯(cuò)Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column...。原因在于MySQL在ONLY_FULL_GROUP_BY模式下SELECT列表中的非聚合列必須出現(xiàn)在GROUP BY中或被函數(shù)包裹。而窗口函數(shù)本身不觸發(fā)GROUP BY檢查但若外層再加GROUP BY比如想統(tǒng)計(jì)每個(gè)用戶登錄次數(shù)就會(huì)撞墻。正確解法先確認(rèn)表結(jié)構(gòu)有主鍵如id再用ROW_NUMBER()且避免在外層加無意義GROUP BY。若必須聚合改用-- 安全寫法用GROUP_CONCAT拼接最近3次時(shí)間規(guī)避GROUP BY限制 SELECT user_id, SUBSTRING_INDEX(GROUP_CONCAT(login_time ORDER BY login_time DESC), ,, 3) AS recent_logins FROM login_log GROUP BY user_id;3.2 PostgreSQL 14DISTINCT ON比窗口函數(shù)更高效但NULLS LAST必須顯式聲明同樣“查每個(gè)用戶最近3次登錄”PostgreSQL標(biāo)準(zhǔn)答案常寫SELECT DISTINCT ON (user_id) user_id, login_time FROM login_log ORDER BY user_id, login_time DESC;這比ROW_NUMBER()快30%以上因?yàn)镈ISTINCT ON是PostgreSQL原生優(yōu)化無需排序整個(gè)結(jié)果集。但致命陷阱在于若login_time允許NULLORDER BY login_time DESC會(huì)把NULL排在最前PostgreSQL默認(rèn)NULLS FIRST導(dǎo)致取到的是NULL記錄而非最新時(shí)間。必須顯式寫ORDER BY user_id, login_time DESC NULLS LAST;否則答案邏輯全錯(cuò)。PDF里若沒寫NULLS LAST就是不合格的“標(biāo)準(zhǔn)答案”。3.3 SQL Server 2022CROSS APPLY是關(guān)系型思維的終極表達(dá)但OFFSET-FETCH有內(nèi)存陷阱SQL Server的答案常是SELECT u.user_id, l.login_time FROM users u CROSS APPLY ( SELECT TOP 3 login_time FROM login_log l2 WHERE l2.user_id u.user_id ORDER BY login_time DESC ) l;CROSS APPLY本質(zhì)是左關(guān)聯(lián)子查詢比JOIN更清晰表達(dá)“對(duì)每個(gè)用戶執(zhí)行一次子查詢”的意圖。但注意TOP 3在SQL Server里不保證穩(wěn)定性若login_time有重復(fù)兩次執(zhí)行可能返回不同記錄。解決方案是加唯一排序字段ORDER BY login_time DESC, id DESC -- id為主鍵確保順序唯一另外若題目要求“分頁查第101-110條”用OFFSET 100 ROWS FETCH NEXT 10 ROWS ONLY但當(dāng)OFFSET過大如OFFSET 100000SQL Server會(huì)掃描前10萬行再丟棄極慢。此時(shí)必須用WHERE id last_id游標(biāo)分頁P(yáng)DF若沒提這點(diǎn)答案就不夠工程化。4. 避坑95%的面試者在PDF題集上栽的5個(gè)血淚現(xiàn)場(chǎng)注意以下問題全部來自真實(shí)面試復(fù)盤和線上題庫提交日志不是理論假設(shè)。每一條都對(duì)應(yīng)PDF里至少3道題的“標(biāo)準(zhǔn)答案”缺陷。4.1 現(xiàn)象COUNT(*)和COUNT(字段)在含NULL數(shù)據(jù)時(shí)結(jié)果不一致但PDF答案全用COUNT(*)原因PDF作者默認(rèn)數(shù)據(jù)無NULL或混淆了“行數(shù)”和“非空值數(shù)”概念。例如題干“統(tǒng)計(jì)各城市有效訂單數(shù)”若city字段有NULL則COUNT(city)只計(jì)非空COUNT(*)計(jì)所有行。解決嚴(yán)格按題干語義選函數(shù)。題干說“有效訂單”必用COUNT(字段)說“訂單總數(shù)”才用COUNT(*)。在測(cè)試數(shù)據(jù)里故意插入NULL驗(yàn)證答案是否魯棒。4.2 現(xiàn)象UPDATE語句在MySQL里成功PostgreSQL里報(bào)錯(cuò)“column reference xxx is ambiguous”原因PDF答案寫UPDATE orders SET statusshipped WHERE user_id IN (SELECT user_id FROM users WHERE vip1)在PostgreSQL里子查詢的user_id未加表別名解析器無法區(qū)分是orders.user_id還是users.user_id。解決所有子查詢字段必須帶表別名如SELECT u.user_id FROM users u。MySQL寬松PostgreSQL嚴(yán)格以嚴(yán)格為準(zhǔn)。4.3 現(xiàn)象BETWEEN日期范圍查詢?cè)诳缒陼r(shí)漏數(shù)據(jù)PDF答案沒處理時(shí)區(qū)原因題干“查2023年所有訂單”答案寫WHERE order_time BETWEEN 2023-01-01 AND 2023-12-31但order_time是DATETIME類型實(shí)際存儲(chǔ)為2023-12-31 23:59:59而BETWEEN包含邊界2023-12-31會(huì)被轉(zhuǎn)成2023-12-31 00:00:00漏掉當(dāng)天所有訂單。解決用開區(qū)間 2023-01-01 AND 2024-01-01或用DATE(order_time) 2023-12-31但喪失索引。4.4 現(xiàn)象GROUP BY后SELECT字段超集MySQL 5.7報(bào)錯(cuò)PDF答案直接復(fù)制MySQL 8.0寫法原因MySQL 5.7默認(rèn)sql_mode含ONLY_FULL_GROUP_BY要求SELECT所有非聚合字段必須在GROUP BY中。PDF答案如SELECT dept, AVG(salary), MAX(name) FROM emp GROUP BY deptMAX(name)雖是聚合但name本身不在GROUP BY5.7報(bào)錯(cuò)。解決要么關(guān)ONLY_FULL_GROUP_BY不推薦要么改用ANY_VALUE(name)MySQL 5.7或重構(gòu)邏輯避免選非分組字段。4.5 現(xiàn)象UNION ALL和UNION混用導(dǎo)致去重錯(cuò)誤PDF答案沒說明性能代價(jià)原因題干“合并銷售表和退貨表”答案用SELECT * FROM sales UNION SELECT * FROM returns但UNION會(huì)排序去重若兩表結(jié)構(gòu)相同但數(shù)據(jù)量大耗時(shí)劇增。實(shí)際應(yīng)UNION ALL除非題干明確要求“去重”。解決UNION ALL是默認(rèn)選擇僅當(dāng)題干出現(xiàn)“唯一”、“不重復(fù)”字眼時(shí)才用UNION并評(píng)估性能影響。5. 把PDF題集變成你的SQL能力儀表盤用SQLFluffCI流水線自動(dòng)校驗(yàn)答案合規(guī)性把PDF當(dāng)靜態(tài)文檔刷題效率低下且無法沉淀能力。真正的高手會(huì)把它變成可執(zhí)行、可度量、可迭代的SQL質(zhì)量門禁。核心思路把每道題的標(biāo)準(zhǔn)答案轉(zhuǎn)成.sql文件用SQLFluff開源SQL Linter做語法/風(fēng)格檢查再用GitHub Actions跑多引擎驗(yàn)證失敗即告警——這樣你不僅知道答案對(duì)不對(duì)更知道它在哪些環(huán)境下會(huì)失效。5.1 結(jié)構(gòu)化題庫把PDF題干和答案拆成機(jī)器可讀的YAMLSQL先用pdfplumber提取PDF文本避開OCR誤差pip install pdfplumber寫腳本parse_pdf.pyimport pdfplumber import re with pdfplumber.open(SQL數(shù)據(jù)庫經(jīng)典編輯面試題.pdf) as pdf: text for page in pdf.pages: text page.extract_text() # 正則匹配題號(hào)、題干、答案假設(shè)格式為1. 【題干】... 標(biāo)準(zhǔn)答案SELECT ... questions re.findall(r(\d)\.\s*【(.*?)】.*?標(biāo)準(zhǔn)答案(SELECT[\s\S]*?;), text, re.DOTALL) for q_num, stem, answer in questions[:5]: # 取前5題示例 with open(fq{q_num}.yml, w, encodingutf-8) as f: f.write(fquestion_number: {q_num}\n) f.write(fstem: \{stem.strip()}\\n) f.write(fanswer_mysql: |\n {answer.strip()}\n) f.write(fanswer_pg: |\n {answer.strip().replace(LIMIT, FETCH FIRST 3 ROWS ONLY)}\n)輸出q1.yml類似question_number: 1 stem: 查詢訂單表中金額大于1000的訂單按創(chuàng)建時(shí)間倒序排列 answer_mysql: | SELECT * FROM orders WHERE amount 1000 ORDER BY create_time DESC; answer_pg: | SELECT * FROM orders WHERE amount 1000 ORDER BY create_time DESC;5.2 SQLFluff配置用規(guī)則集強(qiáng)制工程規(guī)范在項(xiàng)目根目錄建.sqlfluff[sqlfluff] dialect ansi templater jinja [sqlfluff:rules:L010] capitalisation_policy upper [sqlfluff:rules:L016] max_line_length 80 [sqlfluff:rules:L030] allow_scalar True [sqlfluff:rules:L044] comma_style leading關(guān)鍵規(guī)則解讀L010關(guān)鍵字全大寫SELECT/FROM避免select/from混用L016單行不超過80字符逼你拆長條件提升可讀性L030允許標(biāo)量子查詢?nèi)鏢ELECT (SELECT COUNT(*) FROM t2) FROM t1這是復(fù)雜題常用手法L044逗號(hào)前置,寫在行首讓Git diff更清晰——加刪字段時(shí)只多一行 , new_col而非改兩行。運(yùn)行校驗(yàn)sqlfluff lint --dialect mysql q1.sql # 檢查MySQL語法 sqlfluff fix --dialect postgres q1.sql # 自動(dòng)修復(fù)PostgreSQL風(fēng)格5.3 GitHub Actions流水線三引擎并行驗(yàn)證失敗即阻斷.github/workflows/sql-test.ymlname: SQL Interview Test on: [push, pull_request] jobs: test-mysql: runs-on: ubuntu-latest services: mysql: image: mysql:8.0 env: MYSQL_ROOT_PASSWORD: pass123 ports: - 3306:3306 options: --health-cmdmysqladmin ping -h localhost -u root -ppass123 --health-interval10s steps: - uses: actions/checkoutv3 - name: Run MySQL tests run: | sleep 10 # 等MySQL啟動(dòng) mysql -h 127.0.0.1 -P 3306 -u root -ppass123 -e CREATE DATABASE testdb; mysql -h 127.0.0.1 -P 3306 -u root -ppass123 testdb init_data.sql mysql -h 127.0.0.1 -P 3306 -u root -ppass123 testdb -e $(cat q1.sql) || exit 1 test-postgres: # 類似配置略 test-sqlserver: # 類似配置略每次提交SQL文件Actions自動(dòng)在三引擎上跑任一失敗即標(biāo)紅PR。這不是炫技而是把“標(biāo)準(zhǔn)答案”從紙面拉到生產(chǎn)級(jí)可靠性層面——你寫的每一行SQL都經(jīng)過了真實(shí)引擎的編譯、優(yōu)化、執(zhí)行三重考驗(yàn)。6. 我的私藏技巧用執(zhí)行計(jì)劃反推題干隱含約束讓“標(biāo)準(zhǔn)答案”自己開口說話刷題最深的誤區(qū)是把答案當(dāng)終點(diǎn)。我?guī)н^的新人里80%卡在“這題我寫出來了但面試官問‘為什么不用JOIN而用EXISTS’就懵了”。真相是題干里藏著沒明說的約束而執(zhí)行計(jì)劃就是它的X光片。比如一道題“查詢購買過iPhone的用戶中從未買過Mac的用戶”。PDF答案用NOT EXISTS但沒人告訴你如果改成LEFT JOIN ... WHERE mac_id IS NULL在用戶量百萬時(shí)執(zhí)行計(jì)劃會(huì)從NESTED LOOP變成HASH JOIN內(nèi)存暴漲3倍——這就是題干隱含的“大數(shù)據(jù)量”約束。6.1 三步法用EXPLAIN讀出題干沒寫的潛臺(tái)詞以MySQL為例對(duì)任意答案SQL執(zhí)行EXPLAIN FORMATTREE SELECT u.name FROM users u WHERE NOT EXISTS ( SELECT 1 FROM orders o WHERE o.user_id u.id AND o.product Mac );看輸出關(guān)鍵字段rows若顯示1000000說明沒走索引題干暗示“users表無索引”答案必須加FORCE INDEX或改寫filtered若 10說明條件過濾率低題干暗示“Mac訂單占比極小”NOT EXISTS比LEFT JOIN更優(yōu)possible_keys為空但key有值說明走了索引但非最優(yōu)題干暗示“需優(yōu)化索引設(shè)計(jì)”。實(shí)戰(zhàn)案例PDF中一道題答案用IN (SELECT ...)EXPLAIN顯示typeALL全表掃描。我立刻意識(shí)到題干“查詢活躍用戶”中的“活躍”定義模糊但執(zhí)行計(jì)劃暴露了子查詢結(jié)果集太大。于是重寫為INNER JOIN 覆蓋索引性能提升20倍。這比死記硬背答案有用十倍。6.2 建立自己的“執(zhí)行計(jì)劃詞典”把常見模式映射到題干關(guān)鍵詞執(zhí)行計(jì)劃特征對(duì)應(yīng)題干關(guān)鍵詞應(yīng)對(duì)策略typeALL,rows大數(shù)“全量”、“所有”、“未指定條件”必須加索引或用分區(qū)表ExtraUsing temporary; Using filesort“排序”、“分組”、“去重”檢查ORDER BY字段是否在索引中或用SELECT STRAIGHT_JOIN強(qiáng)制連接順序key_len4,refconst“主鍵查詢”、“ID精確匹配”確認(rèn)用了主鍵索引而非普通索引rows1,filtered100.00“唯一”、“精確”、“存在性判斷”優(yōu)先用EXISTS而非JOIN這張表不是背的是我把PDF里50道題的EXPLAIN結(jié)果手工歸類出來的?，F(xiàn)在看到題干“查是否存在”第一反應(yīng)不是寫COUNT(*)0而是EXISTS——因?yàn)镋XISTS的執(zhí)行計(jì)劃永遠(yuǎn)是rows1而COUNT(*)在大數(shù)據(jù)量時(shí)是rows大數(shù)。6.3 終極心法把“標(biāo)準(zhǔn)答案”當(dāng)反例來證偽而不是當(dāng)圣旨來膜拜我至今保留著一個(gè)叫anti_answers的文件夾里面全是PDF里“標(biāo)準(zhǔn)答案”的錯(cuò)誤變體q3_wrong_join.sql把NOT IN改成LEFT JOIN在子查詢含NULL時(shí)返回空結(jié)果q7_wrong_limit.sql用LIMIT替代ROW_NUMBER()在并列排名時(shí)漏數(shù)據(jù)q12_wrong_cast.sqlCAST(2023-01-01 AS DATE)在SQL Server里報(bào)錯(cuò)應(yīng)CONVERT(DATE, 2023-01-01)。每次遇到新題我先寫一個(gè)“看起來合理但實(shí)際錯(cuò)”的版本跑一遍看報(bào)什么錯(cuò)、執(zhí)行計(jì)劃什么樣再對(duì)照PDF答案找差異。這個(gè)過程比直接看答案慢三倍但記住的深刻十倍。因?yàn)槟闶怯缅e(cuò)誤在理解正確而不是用正確在覆蓋錯(cuò)誤。最后說一句實(shí)在話這份PDF的價(jià)值從來不在答案本身而在于它是一把鑰匙——幫你打開數(shù)據(jù)庫引擎的黑匣子看清語法糖背后的執(zhí)行器、優(yōu)化器、事務(wù)管理器如何協(xié)同工作。當(dāng)你能對(duì)著一道題說出“MySQL會(huì)用Index MergePostgreSQL會(huì)選Bitmap ScanSQL Server會(huì)走Key Lookup”你就已經(jīng)超越了90%的面試者。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取