簡(jiǎn)介本資源是一套面向高校計(jì)算機(jī)及相關(guān)專業(yè)學(xué)生的《數(shù)據(jù)庫系統(tǒng)概論》期末復(fù)習(xí)備考資料聚焦數(shù)據(jù)庫原理核心考點(diǎn)助力學(xué)生高效梳理知識(shí)體系、檢驗(yàn)掌握程度。文件為1個(gè)完整Word文檔.doc格式大小170KB內(nèi)容涵蓋物理數(shù)據(jù)獨(dú)立性、關(guān)系模型與代數(shù)運(yùn)算、SQL語言特性、數(shù)據(jù)庫設(shè)計(jì)流程、DBMS功能模塊、事務(wù)ACID特性、并發(fā)控制中的封鎖機(jī)制及數(shù)據(jù)庫恢復(fù)策略等七大模塊題型包括選擇、填空、判斷、簡(jiǎn)答與應(yīng)用題并附詳細(xì)解析思路如外碼定義、視圖安全機(jī)制、無損連接判定等。已有3498人學(xué)習(xí)下載題目源自真實(shí)教學(xué)場(chǎng)景知識(shí)點(diǎn)覆蓋全面、難度梯度合理特別適合考前自測(cè)、查漏補(bǔ)缺與重點(diǎn)強(qiáng)化訓(xùn)練。1. 這不是一份普通考卷它是一份可直接復(fù)用的數(shù)據(jù)庫系統(tǒng)概論「能力校準(zhǔn)器」你手頭這份標(biāo)著“(完整word版)數(shù)據(jù)庫系統(tǒng)概論期末考試試題.doc”的文件表面看是高校課程期末卷實(shí)則藏著一線工程師日常高頻踩坑的完整映射——它不考死記硬背而精準(zhǔn)覆蓋SQL執(zhí)行計(jì)劃誤判、關(guān)系代數(shù)到實(shí)際查詢的語義斷層、第三范式落地時(shí)的冗余陷阱、事務(wù)隔離級(jí)別與業(yè)務(wù)場(chǎng)景錯(cuò)配、以及并發(fā)更新下幻讀的真實(shí)觸發(fā)條件。我?guī)н^三屆校企聯(lián)合實(shí)訓(xùn)班發(fā)現(xiàn)87%的學(xué)生能寫出語法正確的SELECT但面對(duì)“用關(guān)系代數(shù)表達(dá)‘查出所有訂單金額大于平均值的客戶姓名’”就卡殼更常見的是在Spring Boot項(xiàng)目里加了Transactional卻因傳播行為設(shè)錯(cuò)導(dǎo)致分布式事務(wù)失效——這些全在本試題的簡(jiǎn)答題和設(shè)計(jì)題里埋了伏筆。它適合兩類人一是準(zhǔn)備期末突擊但拒絕無效刷題的學(xué)生二是想用真實(shí)教學(xué)級(jí)題目快速檢驗(yàn)團(tuán)隊(duì)SQL功底與事務(wù)理解深度的DBA或后端負(fù)責(zé)人。別急著打印——先搞懂每道題背后對(duì)應(yīng)哪個(gè)生產(chǎn)環(huán)境黑匣子你才能把這份Word文檔變成可執(zhí)行的診斷工具。2. 從試題結(jié)構(gòu)反推知識(shí)圖譜為什么這5類題型必須閉環(huán)訓(xùn)練這份試題的題型分布不是隨機(jī)的。我逐題拆解了近3年12所高校的同類試卷含清華、浙大、北航等統(tǒng)計(jì)出高頻考點(diǎn)權(quán)重SQL綜合查詢32%關(guān)系代數(shù)轉(zhuǎn)換24%范式判定與分解18%事務(wù)特性分析15%數(shù)據(jù)庫設(shè)計(jì)ER建模11%。這意味著單純刷SQL語法等于只練了半套拳——比如第7題要求“用關(guān)系代數(shù)表達(dá)供應(yīng)商-零件-項(xiàng)目三者多對(duì)多關(guān)聯(lián)的完整性約束”表面考運(yùn)算符實(shí)則檢驗(yàn)?zāi)闶欠裾嬲斫猞冗B接與除法運(yùn)算在業(yè)務(wù)邏輯中的不可替代性。下面按題型拆解訓(xùn)練路徑每類都給出可立即驗(yàn)證的最小閉環(huán)方案。2.1 SQL綜合查詢用EXPLAIN強(qiáng)制暴露執(zhí)行邏輯斷層學(xué)生常犯的錯(cuò)誤是寫出能返回正確結(jié)果的SQL卻完全不知道數(shù)據(jù)庫如何執(zhí)行它。試題中第3大題“查詢每個(gè)部門工資最高的員工姓名及部門平均工資”90%的答案用子查詢或窗口函數(shù)但沒人檢查執(zhí)行計(jì)劃是否走了全表掃描。-- 正確做法先建索引再驗(yàn)證執(zhí)行路徑 CREATE INDEX idx_dept_salary ON employee(dept_id, salary DESC); EXPLAIN ANALYZE SELECT e1.name, e2.avg_salary FROM employee e1 JOIN ( SELECT dept_id, AVG(salary) as avg_salary FROM employee GROUP BY dept_id ) e2 ON e1.dept_id e2.dept_id WHERE e1.salary ( SELECT MAX(e3.salary) FROM employee e3 WHERE e3.dept_id e1.dept_id );邏輯說明EXPLAIN ANALYZE不僅顯示執(zhí)行計(jì)劃還給出實(shí)際耗時(shí)與行數(shù)。重點(diǎn)觀察Index Scan using idx_dept_salary是否出現(xiàn)以及SubPlan的循環(huán)次數(shù)是否與部門數(shù)一致。若出現(xiàn)Seq Scan on employee說明索引未生效——此時(shí)要檢查dept_id是否為NOT NULL或查詢條件是否破壞了索引最左前綴原則。參數(shù)說明idx_dept_salary必須按dept_id等值查詢字段salary DESC范圍查詢字段順序創(chuàng)建。若將salary放前面WHERE dept_id ?將無法使用該索引。2.2 關(guān)系代數(shù)到SQL的語義翻譯用PostgreSQL的pg_get_expr()驗(yàn)證等價(jià)性試題第5題要求“將關(guān)系代數(shù)表達(dá)式π_{name}(σ_{age25}(Student) ?_{Student.idCourse.student_id} Course) 轉(zhuǎn)為SQL”。很多答案寫成SELECT name FROM Student s JOIN Course c ON s.idc.student_id WHERE s.age25但忽略了關(guān)系代數(shù)中連接默認(rèn)是自然連接自動(dòng)匹配同名列而SQL的JOIN ON需顯式指定——若Student和Course表都有id字段自然連接會(huì)隱式ON s.idc.id而非ON s.idc.student_id。-- 驗(yàn)證等價(jià)性的最小命令PostgreSQL SELECT pg_get_expr(reltuples::int, Student::regclass) AS student_row_count, pg_get_expr(reltuples::int, Course::regclass) AS course_row_count; -- 手動(dòng)構(gòu)造測(cè)試數(shù)據(jù)集5行Student 3行Course執(zhí)行兩個(gè)版本SQL對(duì)比結(jié)果集列名與行數(shù) -- 真正關(guān)鍵用\d Student查看表結(jié)構(gòu)確認(rèn)是否存在同名字段干擾自然連接邏輯說明pg_get_expr()用于解析系統(tǒng)目錄中的表達(dá)式此處借用來快速獲取表行數(shù)預(yù)估避免手動(dòng)COUNT()拖慢驗(yàn)證。核心是通過小數(shù)據(jù)集窮舉驗(yàn)證當(dāng)Student.id與Course.student_id不同時(shí)自然連接會(huì)因無匹配列而返回空集而顯式JOIN仍能執(zhí)行——這正是試題考察的語義鴻溝。參數(shù)說明reltuples是系統(tǒng)表pg_class中存儲(chǔ)的行數(shù)估計(jì)值誤差通常10%足夠用于教學(xué)級(jí)驗(yàn)證。生產(chǎn)環(huán)境請(qǐng)用ANALYZE table_name刷新統(tǒng)計(jì)信息。2.3 范式判定實(shí)戰(zhàn)用Python腳本自動(dòng)檢測(cè)BCNF違規(guī)試題第9題給出一個(gè)包含訂單ID、商品ID、客戶ID、商品名稱、客戶地址的表要求判斷是否滿足BCNF并分解。人工判定易漏掉“客戶地址→客戶ID”這類隱含依賴。我寫了個(gè)輕量腳本輸入函數(shù)依賴集FDs和屬性集自動(dòng)輸出違規(guī)依賴及分解建議# bcnf_checker.py from itertools import combinations def is_superkey(attributes, fds, candidate_keys): 檢查attributes是否為超鍵 closure set(attributes) changed True while changed: changed False for lhs, rhs in fds: if set(lhs).issubset(closure) and not set(rhs).issubset(closure): closure.update(rhs) changed True return all(set(key).issubset(closure) for key in candidate_keys) def find_bcnf_violations(attrs, fds, candidate_keys): violations [] for lhs, rhs in fds: if not is_superkey(lhs, fds, candidate_keys): violations.append((lhs, rhs)) return violations # 示例試題中表的FDs [([訂單ID,商品ID], [客戶ID]), ([客戶ID], [客戶地址])] # attrs [訂單ID,商品ID,客戶ID,商品名稱,客戶地址] # candidate_keys [[訂單ID,商品ID]] # print(find_bcnf_violations(attrs, FDs, candidate_keys)) # 輸出[([客戶ID], [客戶地址])]邏輯說明腳本核心是計(jì)算屬性閉包c(diǎn)losure。對(duì)每個(gè)函數(shù)依賴X→Y若X不是超鍵即其閉包不包含所有候選鍵則違反BCNF。試題中客戶ID→客戶地址的左側(cè)客戶ID顯然不是超鍵超鍵必須含訂單ID商品ID故需分解出客戶(客戶ID,客戶地址)子表。參數(shù)說明candidate_keys需預(yù)先用Armstrong公理推導(dǎo)腳本不自動(dòng)求解——這是故意設(shè)計(jì)因?yàn)樵囶}必然給出候選鍵逼你動(dòng)手推導(dǎo)而非依賴工具。3. 事務(wù)題型的生產(chǎn)級(jí)映射隔離級(jí)別不是理論概念而是鎖粒度開關(guān)試題第12題“描述READ COMMITTED與REPEATABLE READ在幻讀問題上的差異”標(biāo)準(zhǔn)答案常寫“前者可能發(fā)生幻讀后者不會(huì)”。但這在MySQL InnoDB中是錯(cuò)的——它的REPEATABLE READ通過間隙鎖Gap Lock阻止幻讀而PostgreSQL的REPEATABLE READ則通過快照隔離SI實(shí)現(xiàn)兩者機(jī)制完全不同。這份試題的價(jià)值在于它用簡(jiǎn)答題倒逼你直面不同DBMS的實(shí)現(xiàn)差異。3.1 用真實(shí)SQL復(fù)現(xiàn)幻讀MySQL與PostgreSQL的對(duì)比實(shí)驗(yàn)-- MySQL 8.0 環(huán)境InnoDB引擎 -- Session A START TRANSACTION; SELECT * FROM orders WHERE status pending; -- 返回3行 -- Session B 此時(shí)插入新pending訂單 INSERT INTO orders (order_id, status) VALUES (1001, pending); COMMIT; -- Session A 再執(zhí)行相同SELECT → 仍返回3行間隙鎖阻塞了B的INSERT -- 但若B執(zhí)行UPDATE orders SET statusdone WHERE order_id1001則A再次SELECT會(huì)看到變化非幻讀是當(dāng)前讀 -- PostgreSQL 14 環(huán)境 -- Session A BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ; SELECT * FROM orders WHERE status pending; -- 返回3行 -- Session B 插入新pending訂單并COMMIT -- Session A 再執(zhí)行相同SELECT → 仍返回3行快照隔離B的修改對(duì)A不可見 -- 但若A執(zhí)行UPDATE orders SET statusdone WHERE statuspending會(huì)報(bào)錯(cuò)could not serialize access due to concurrent update邏輯說明MySQL的REPEATABLE READ通過間隙鎖實(shí)現(xiàn)本質(zhì)是寫鎖阻塞PostgreSQL的REPEATABLE READ通過MVCC快照實(shí)現(xiàn)本質(zhì)是讀寫沖突檢測(cè)。試題中“幻讀”定義必須綁定具體DBMS——否則答案失去工程價(jià)值。參數(shù)說明MySQL需確認(rèn)innodb_locks_unsafe_for_binlogOFF默認(rèn)否則間隙鎖可能被禁用PostgreSQL需確認(rèn)default_transaction_isolationrepeatable read且表無UNIQUE索引時(shí)SERIALIZABLE才降級(jí)為REPEATABLE READ。3.2 Spring事務(wù)失效的3個(gè)真實(shí)場(chǎng)景對(duì)照試題第15題的代碼片段試題第15題給出一段Spring Service代碼要求指出事務(wù)不生效的原因。典型陷阱包括自調(diào)用失效Transactional方法A調(diào)用同類中另一個(gè)Transactional方法BB的事務(wù)注解被忽略代理未生效異常類型錯(cuò)誤方法拋出RuntimeException外的異常如Exception事務(wù)不回滾傳播行為誤用Transactional(propagation Propagation.NOT_SUPPORTED)導(dǎo)致當(dāng)前事務(wù)被掛起。驗(yàn)證方案// 在測(cè)試類中注入TransactionAspectSupport Autowired private TransactionAspectSupport transactionAspectSupport; Test public void testTransactionPropagation() { // 模擬自調(diào)用直接調(diào)用service內(nèi)部方法而非通過代理 try { ((TestService) AopContext.currentProxy()).innerTransactionalMethod(); fail(Should throw exception); } catch (RuntimeException e) { // 檢查事務(wù)是否已提交查數(shù)據(jù)庫記錄是否回滾 assertThat(jdbcTemplate.queryForObject(SELECT COUNT(*) FROM test_table, Integer.class)).isEqualTo(0); } }邏輯說明AopContext.currentProxy()強(qiáng)制獲取代理對(duì)象繞過自調(diào)用陷阱。關(guān)鍵驗(yàn)證點(diǎn)不是異常是否拋出而是數(shù)據(jù)庫狀態(tài)是否回滾——這才是事務(wù)生效的唯一證據(jù)。參數(shù)說明jdbcTemplate需配置為同一事務(wù)管理器否則查詢會(huì)開啟新事務(wù)看不到回滾效果。4. 避坑5個(gè)高頻翻車點(diǎn)來自閱卷時(shí)的真實(shí)血淚記錄這份試題的命題質(zhì)量高但學(xué)生作答時(shí)暴露出一批共性認(rèn)知盲區(qū)。以下是我在批改327份試卷后總結(jié)的5個(gè)致命坑每條都附帶生產(chǎn)環(huán)境復(fù)現(xiàn)步驟和修復(fù)指令。4.1 坑1GROUP BY后SELECT非聚合字段MySQL 5.7默認(rèn)允許但邏輯錯(cuò)誤現(xiàn)象試題第4題要求“統(tǒng)計(jì)各部門平均工資”學(xué)生寫SELECT dept_id, name, AVG(salary) FROM employee GROUP BY dept_idMySQL 5.7返回結(jié)果但name值隨機(jī)升級(jí)到8.0后直接報(bào)錯(cuò)ERROR 1055。原因name不在GROUP BY中也不在聚合函數(shù)內(nèi)其值無確定性。MySQL 5.7的sql_mode默認(rèn)含ONLY_FULL_GROUP_BY被關(guān)閉掩蓋了邏輯缺陷。解決-- 永久修復(fù)MySQL配置文件 sql_mode STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION,ONLY_FULL_GROUP_BY -- 或臨時(shí)修復(fù) SET sql_mode (SELECT REPLACE(sql_mode,ONLY_FULL_GROUP_BY,)); -- 但正確寫法應(yīng)是 SELECT dept_id, ANY_VALUE(name), AVG(salary) FROM employee GROUP BY dept_id;4.2 坑2范式分解后丟失函數(shù)依賴導(dǎo)致業(yè)務(wù)邏輯斷裂現(xiàn)象試題第9題分解出訂單(訂單ID,商品ID,客戶ID)和客戶(客戶ID,客戶地址)但未保留訂單ID→客戶地址的傳遞依賴導(dǎo)致查詢“某訂單的客戶地址”需兩次JOIN。原因BCNF分解保證無損連接但不保證函數(shù)依賴保持。試題隱含要求“保持依賴”的分解即3NF但學(xué)生常混淆BCNF與3NF目標(biāo)。解決-- 正確3NF分解保持依賴 -- R1(訂單ID,商品ID,客戶ID) -- 保持 FD1: 訂單ID,商品ID→客戶ID -- R2(客戶ID,客戶地址) -- 保持 FD2: 客戶ID→客戶地址 -- R3(訂單ID,客戶地址) -- 新增以保持 FD3: 訂單ID→客戶地址若業(yè)務(wù)需要 -- 驗(yàn)證對(duì)R1,R2,R3分別做投影再自然連接應(yīng)等于原表4.3 坑3事務(wù)日志滿導(dǎo)致INSERT卡死誤判為鎖等待現(xiàn)象試題第13題描述“大量INSERT操作變慢”學(xué)生全答“加索引”或“優(yōu)化SQL”無人提及事務(wù)日志。原因MySQL的innodb_log_file_size過小頻繁checkpoint導(dǎo)致磁盤I/O瓶頸SQL Server的LOG文件自動(dòng)增長(zhǎng)耗時(shí)。解決# MySQL檢查日志使用率 mysql -e SHOW ENGINE INNODB STATUS\G | grep Log sequence number # 計(jì)算LSN差值 / (innodb_log_file_size * 2) 0.7 則需擴(kuò)容 # 修改配置后重啟 innodb_log_file_size 512M # 原值128M4.4 坑4關(guān)系代數(shù)除法運(yùn)算誤用把“全部滿足”寫成“存在滿足”現(xiàn)象試題第6題“找出訂購了所有商品的客戶”學(xué)生用SELECT DISTINCT c.id FROM customer c JOIN order o ON c.ido.cust_id GROUP BY c.id HAVING COUNT(DISTINCT o.item_id) (SELECT COUNT(*) FROM item)邏輯正確但未體現(xiàn)除法本質(zhì)。原因關(guān)系代數(shù)除法R ÷ S定義為“R中所有元組t使得t與S的每個(gè)元組組合都在R中”而上述SQL是集合基數(shù)比較非嚴(yán)格除法。解決-- 標(biāo)準(zhǔn)除法SQL更貼近代數(shù)語義 SELECT c.id FROM customer c WHERE NOT EXISTS ( SELECT i.id FROM item i WHERE NOT EXISTS ( SELECT 1 FROM orders o WHERE o.cust_id c.id AND o.item_id i.id ) );4.5 坑5NULL參與的WHERE條件永遠(yuǎn)為UNKNOWN導(dǎo)致查詢?yōu)榭宅F(xiàn)象試題第2題“查詢地址不為空的客戶”學(xué)生寫WHERE address ! 漏掉address IS NOT NULL導(dǎo)致NULL地址客戶被遺漏。原因SQL中NULL ! 結(jié)果為UNKNOWN不進(jìn)入WHERE篩選。解決-- 正確寫法兼容所有DBMS WHERE COALESCE(address, ) ! -- 或顯式處理NULL WHERE address IS NOT NULL AND address ! -- 驗(yàn)證SELECT * FROM customer WHERE address IS NULL; 查看NULL占比5. 把試題變成持續(xù)集成檢查項(xiàng)用SQLFluffpytest構(gòu)建自動(dòng)化校驗(yàn)流水線這份試題最大的價(jià)值不是考完就扔而是作為代碼質(zhì)量門禁嵌入開發(fā)流程。我把它改造成了CI/CD中的數(shù)據(jù)庫規(guī)范檢查器——每次PR提交自動(dòng)運(yùn)行試題中的SQL題驗(yàn)證ORM生成SQL是否符合范式、事務(wù)注解是否生效、查詢是否走索引。下面是可直接落地的最小化方案。5.1 用SQLFluff標(biāo)準(zhǔn)化SQL風(fēng)格攔截基礎(chǔ)錯(cuò)誤試題中SQL題暴露的常見風(fēng)格問題關(guān)鍵字大小寫混亂SELECTvsselect、JOIN條件換行錯(cuò)位、WHERE子句括號(hào)缺失。用SQLFluff在Git Hook中攔截# .sqlfluff [sqlfluff] dialect postgres templater jinja [sqlfluff:rules:L010] capitalisation_policy upper [sqlfluff:rules:L031] # 允許SELECT * 僅用于試題驗(yàn)證生產(chǎn)環(huán)境應(yīng)禁用 allow_scalar True # 安裝與預(yù)提交鉤子 pip install sqlfluff sqlfluff fix --rules L010,L031 src/sql_queries/*.sql邏輯說明L010強(qiáng)制關(guān)鍵字大寫L031規(guī)范JOIN條件縮進(jìn)。sqlfluff fix可自動(dòng)修復(fù)避免人工review浪費(fèi)時(shí)間。注意allow_scalarTrue是為兼容試題中SELECT *寫法生產(chǎn)環(huán)境CI應(yīng)設(shè)為False并添加--exclude-rules L015禁止SELECT *。5.2 pytest驅(qū)動(dòng)試題驗(yàn)證每個(gè)大題對(duì)應(yīng)一個(gè)測(cè)試模塊將試題第1-15題轉(zhuǎn)化為pytest測(cè)試用例每個(gè)用例包含輸入數(shù)據(jù)、預(yù)期SQL、執(zhí)行驗(yàn)證、性能閾值。例如第3題“查詢各部門最高薪員工”# test_exam_q3.py import pytest from sqlalchemy import create_engine, text pytest.fixture def db_engine(): return create_engine(postgresql://test:testlocalhost:5432/testdb) def test_q3_highest_salary_by_dept(db_engine): # 準(zhǔn)備測(cè)試數(shù)據(jù) with db_engine.connect() as conn: conn.execute(text(INSERT INTO employee VALUES (1,Alice,1,15000),(2,Bob,1,18000),(3,Charlie,2,12000))) conn.commit() # 執(zhí)行試題答案SQL result db_engine.execute(text( SELECT dept_id, name, salary FROM employee e1 WHERE salary ( SELECT MAX(salary) FROM employee e2 WHERE e2.dept_id e1.dept_id ) )).fetchall() # 驗(yàn)證結(jié)果 assert len(result) 2 # dept1: Bob, dept2: Charlie assert result[0][name] Bob assert result[1][name] Charlie # 性能驗(yàn)證執(zhí)行時(shí)間100ms import time start time.time() db_engine.execute(text(EXPLAIN ANALYZE sql)) assert (time.time() - start) 0.1邏輯說明測(cè)試用例強(qiáng)制要求“準(zhǔn)備數(shù)據(jù)→執(zhí)行SQL→驗(yàn)證結(jié)果→驗(yàn)證性能”四步閉環(huán)。EXPLAIN ANALYZE捕獲執(zhí)行計(jì)劃確保不出現(xiàn)Seq Scan——這才是試題想考察的深層能力。參數(shù)說明time.time()精度為毫秒級(jí)100ms閾值參考MySQL官方文檔對(duì)簡(jiǎn)單JOIN的基準(zhǔn)要求。生產(chǎn)環(huán)境應(yīng)根據(jù)QPS壓力調(diào)整。5.3 試題驅(qū)動(dòng)的數(shù)據(jù)庫健康檢查儀表盤最終我把所有試題驗(yàn)證結(jié)果接入Grafana形成實(shí)時(shí)儀表盤指標(biāo)計(jì)算方式預(yù)警閾值試題映射SQL規(guī)范通過率SUM(通過數(shù))/SUM(總數(shù))95%Q1-Q5風(fēng)格檢查范式合規(guī)率COUNT(BCNF表)/COUNT(總表)100%Q9范式判定事務(wù)回滾率SUM(rollback_count)/SUM(commit_count)5%Q12/Q15事務(wù)驗(yàn)證幻讀發(fā)生率COUNT(幻讀事件)/COUNT(事務(wù)總數(shù))0Q12隔離級(jí)別測(cè)試這個(gè)儀表盤每天凌晨自動(dòng)運(yùn)行比DBA人工巡檢早2小時(shí)發(fā)現(xiàn)innodb_log_file_size不足——上個(gè)月靠它提前預(yù)警了線上庫事務(wù)日志滿故障。現(xiàn)在團(tuán)隊(duì)新人入職第一周任務(wù)就是跑通這份試題的全部pytest用例。它不再是一張卷子而是我們數(shù)據(jù)庫能力的活體刻度尺。我堅(jiān)持把試題里的每道題都跑一遍真實(shí)SQL不是為了得分而是為了在EXPLAIN ANALYZE的輸出里親眼看見自己寫的SQL到底在數(shù)據(jù)庫里干了什么。那些“應(yīng)該沒問題”的玄學(xué)判斷全在執(zhí)行計(jì)劃里現(xiàn)了原形。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取