數(shù)據(jù)庫系統(tǒng)這門課做實驗的心態(tài)往往分兩個階段。前三次實驗大家基本都在跟 SQL 語法纏斗——建表、增刪改查、寫子查詢跑出正確結(jié)果就很有成就感。但到了實驗四味道突然變了它不再只問你“這條查詢怎么寫”而是開始問“這條查詢憑什么快”“這筆業(yè)務(wù)憑什么不會出錯”“這個規(guī)則憑什么自動執(zhí)行”。說白了實驗四要把你的視野從“寫對”拉到“寫好”從單條語句拉到數(shù)據(jù)庫運行機制的整體理解。這篇文章我就拿某高校軟件學(xué)院數(shù)據(jù)庫系統(tǒng)實驗四的完整過程來講把視圖、索引、存儲過程、事務(wù)和觸發(fā)器這五個點串進一條業(yè)務(wù)線里逐步拆解每一步為什么要這么做、怎么做才能得分、實驗室里最容易翻車的地方在哪。正在啃這個實驗的同學(xué)可以直接照做想補短板或者以后準備做助教的人也可以把它當(dāng)一份現(xiàn)成的備課筆記。1. 實驗四到底在考什么需求拆解與整體思路1.1 從課程主線看實驗四的定位數(shù)據(jù)庫系統(tǒng)的實驗安排一般有一條很清晰的遞進線。實驗一建庫建表練的是 DDL核心是熟悉字段類型、主鍵外鍵約束實驗二做增刪改查練的是 DML核心是單表的 CURD實驗三開始上難度多表連接、子查詢、聚合函數(shù)核心是“把復(fù)雜查詢寫出來”到了實驗四重點就變成了“把數(shù)據(jù)庫用明白”。這里的“用明白”包含幾個層面。第一能不能創(chuàng)建視圖來簡化高頻查詢第二能不能用索引讓查詢真正變快而不是停留在“理論上該快”第三能不能用存儲過程把多步業(yè)務(wù)操作打包成一個可調(diào)用的單元第四能不能用事務(wù)保證數(shù)據(jù)在并發(fā)和出錯環(huán)境下依然一致第五能不能用觸發(fā)器實現(xiàn)數(shù)據(jù)的自動約束和審計。這五個點都不是新語法那么簡單它們的共同特征是每一個都是在回答“為什么”。我見過不少同學(xué)實驗四做得稀里糊涂代碼都是從網(wǎng)上抄來的運行能出結(jié)果就提交了。老師驗收時隨口問一句“你這個視圖為什么比直接查表方便”就卡住了。所以做這個實驗之前先別急著敲代碼把五件事的邏輯關(guān)系想清楚比多寫十條 SQL 有用得多。1.2 一條業(yè)務(wù)線串起五個知識點實驗四最好的做法是找一條業(yè)務(wù)線把這五個知識點全部串起來。我當(dāng)時帶學(xué)生的時候推薦他們統(tǒng)一采用“學(xué)生成績管理系統(tǒng)”的場景因為課程所有同學(xué)都能理解而且非常自然。場景是這樣設(shè)計的學(xué)生選課、考試、成績錄入然后教務(wù)需要經(jīng)常按課程查看班級成績分布。圍繞這個場景五個知識點的出場順序非常順經(jīng)常會寫“某門課所有學(xué)生的成績和平均分”這種長 SQL于是封裝成視圖成績表數(shù)據(jù)量大了以后查詢越來越慢于是給高頻查詢字段建索引成績錄錯要修改但不能改一半于是用事務(wù)保證原子性再用存儲過程把“檢查記錄-更新-提交/回滾”封裝起來學(xué)生成績一變就要留痕人工在應(yīng)用里寫日志容易漏于是靠觸發(fā)器自動寫入審計表。五個點被一條業(yè)務(wù)線串起來之后實驗報告也不再是五個孤立的小題而是“我要在什么場景下解決什么問題、為什么選這個手段、效果如何”的完整閉環(huán)。這個思路本身就是拿高分的底子。2. 環(huán)境與數(shù)據(jù)準備動手寫 SQL 之前的必修課2.1 數(shù)據(jù)庫版本和客戶端怎么選實驗四用的數(shù)據(jù)庫管理系統(tǒng)不同學(xué)校規(guī)定不同。如果你所在課程用的是課內(nèi)統(tǒng)一安裝的版本那沒什么好挑的如果沒規(guī)定我的建議是選 MySQL 8.0原因很實在開源免費、安裝包小、出問題搜索引擎一搜一大堆答案助教也最熟悉?？蛻舳朔矫?DBeaver 和 Navicat 都可以。DBeaver 是免費的跨平臺適合學(xué)生Navicat 對初學(xué)者更友好圖形界面直觀查看表結(jié)構(gòu)和執(zhí)行計劃的時候體驗不錯。我這里多說一句有些同學(xué)偷懶直接在某在線 SQL 網(wǎng)站上做實驗我不太推薦。實驗四不像前面幾次實驗它需要反復(fù)切換會話去復(fù)現(xiàn)事務(wù)并發(fā)問題還需要看執(zhí)行計劃和鎖等待信息在線網(wǎng)站根本提供不了這些功能。安裝 MySQL 時有兩個坑提前說一下。一是端口沖突3306 經(jīng)常被之前殘留的舊版本占用裝完連不上先檢查端口二是字符集安裝后默認可能是 latin1后面中文亂碼基本都是從這里埋下的我建議建庫時直接顯式指定 utf8mb4。2.2 基礎(chǔ)表結(jié)構(gòu)設(shè)計與樣本數(shù)據(jù)構(gòu)造實驗四的表結(jié)構(gòu)不需要很復(fù)雜三張核心表就夠了學(xué)生表 student、課程表 course、選課成績表 sc。結(jié)構(gòu)參考如下CREATE DATABASE db_exp4 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE TABLE student ( sno CHAR(9) PRIMARY KEY, sname VARCHAR(20) NOT NULL, sex CHAR(1) DEFAULT 男, dept VARCHAR(30), enroll_year YEAR ); CREATE TABLE course ( cno CHAR(4) PRIMARY KEY, cname VARCHAR(40) NOT NULL, credit DECIMAL(3,1), semester VARCHAR(10) ); CREATE TABLE sc ( sno CHAR(9), cno CHAR(4), score DECIMAL(5,2), PRIMARY KEY (sno, cno), FOREIGN KEY (sno) REFERENCES student(sno), FOREIGN KEY (cno) REFERENCES course(cno) );注意兩個細節(jié)一是主鍵用學(xué)號、課程號這種有業(yè)務(wù)含義的字段實驗場景里沒問題生產(chǎn)環(huán)境我會建議用自增 ID但這里沒必要繞遠二是成績用 DECIMAL(5,2)表示三位整數(shù)加兩位小數(shù)比用 INT 精確得多也方便后面算平均分。樣本數(shù)據(jù)這塊很多人不重視覺得隨便插幾十條就行。但我可以明確告訴你實驗四里“數(shù)據(jù)量”直接決定你索引優(yōu)化的效果能不能體現(xiàn)出來。只有幾十條記錄全表掃描也在一毫秒以內(nèi)你建索引前后的對比根本看不出來。我當(dāng)時會讓同學(xué)寫一個小腳本生成幾百到上千條選課記錄分數(shù)分布要盡量自然別全是 90 分以上否則后面的視圖統(tǒng)計和成績分布分析會失真。數(shù)據(jù)里還應(yīng)該故意制造一些“不完美”的情況比如某些學(xué)生沒有選課有些課程沒有任何學(xué)生選。這些數(shù)據(jù)在后面驗證視圖的外連接、聚合函數(shù)時非常有用能讓你發(fā)現(xiàn)“用內(nèi)連接統(tǒng)計會丟數(shù)據(jù)”這個經(jīng)典問題。2.3 腳本組織與命名約定實驗四的代碼量明顯比前三大多了如果全堆在一個 SQL 文件里執(zhí)行的時候報錯都不知道錯在哪一行。我習(xí)慣把腳本按功能拆成多個文件01_schema.sql建庫建表、建約束02_data.sql插入樣本數(shù)據(jù)03_view_index.sql創(chuàng)建視圖和索引04_proc_trigger.sql存儲過程、觸發(fā)器、事務(wù)操作05_query.sql驗證用的查詢語句06_test.sql完整的驗收測試流程這樣做的第一個好處是調(diào)試定位快哪個文件報錯就改哪個文件不需要在一大坨代碼里翻來翻去。第二個好處是驗收的時候助教要求“從零開始執(zhí)行一遍”你按文件順序跑一次就能過不會因為某段代碼在后面引用了前面還沒創(chuàng)建的視圖而報錯。命名規(guī)范同樣值得養(yǎng)成習(xí)慣視圖用 v_ 開頭存儲過程用 sp_ 開頭觸發(fā)器用 trg_ 開頭函數(shù)用 fn_ 開頭。學(xué)校不會強制要求這些但這是行業(yè)里通行的經(jīng)驗寫了以后報告看起來專業(yè)很多也給自己省不少麻煩。3. 視圖和索引最基礎(chǔ)也最容易丟分的地方3.1 視圖的本質(zhì)與創(chuàng)建要點視圖很多人第一次接觸時會覺得很玄乎其實它就是一個命名的查詢。你每次都要寫一遍“學(xué)生選課統(tǒng)計”的長 SQL不如把它存成一個虛擬表以后直接查它。視圖不占物理存儲空間數(shù)據(jù)還是存在原來的表里所以它不會讓查詢本身變快但能讓查詢語句變短、邏輯變清晰還能隱藏底層表的敏感字段。我建議實驗里至少創(chuàng)建一個“學(xué)生平均成績”的視圖CREATE OR REPLACE VIEW v_stu_avg AS SELECT s.sno, s.sname, COUNT(sc.cno) AS course_count, ROUND(AVG(sc.score), 2) AS avg_score FROM student s LEFT JOIN sc ON s.sno sc.sno GROUP BY s.sno, s.sname;這里必須用 LEFT JOIN不能是 INNER JOIN。原因剛才提到過有些學(xué)生一門課都沒選內(nèi)連接會把他們在結(jié)果里抹掉統(tǒng)計就丟失了這部分記錄。這就是一個典型的“看起來全對、實際邏輯有漏洞”的點實驗報告里能主動寫出為什么選外連接印象分馬上不一樣。視圖還有一個容易踩的坑寫視圖定義時用了SELECT *。剛開始圖省事后來你給原表加了一個字段視圖也跟著變但有些老代碼早就寫死了字段順序結(jié)果接口輸出全亂。實驗里不會鬧這么大動靜但養(yǎng)成習(xí)慣視圖里永遠顯式列出字段。3.2 索引設(shè)計的取舍索引為什么能讓查詢變快我常用一個生活類比一本幾千頁的工具書你要找一個關(guān)鍵詞一頁一頁翻就是全表掃描看目錄定位到頁碼就是索引查找。數(shù)據(jù)庫里的索引通常用 B 樹實現(xiàn)查詢從“順序掃全表”變成“樹里跳轉(zhuǎn)”復(fù)雜度從 O(n) 降到 O(log n)數(shù)據(jù)量越大差距越明顯。但索引不是越多越好這是新手最容易走極端的地方。每建一個索引寫入時都要多維護一棵樹等于每次插入和更新都變慢了。所以建索引的原則是高頻查詢條件字段、外連接字段、排序字段才值得建寫多讀少的表要克制。實驗里我會讓同學(xué)做一組對比先不建索引跑一個“統(tǒng)計某門課程 90 分以上人數(shù)”的查詢?nèi)缓蠼ㄋ饕鼵REATE INDEX idx_sc_cno_score ON sc(cno, score);再去跑同一句記錄耗時對比。復(fù)合索引 (cno, score) 同時覆蓋了“課程號過濾”和“分數(shù)范圍判斷”查詢只需要在某個課程范圍的索引區(qū)間內(nèi)做掃描不需要回表碰成績數(shù)據(jù)。這個對比實驗寫進報告比空談“索引能優(yōu)化查詢”有說服力太多。3.3 用執(zhí)行計劃驗證索引而不是靠感覺很多同學(xué)建完索引以后就默認“它生效了”這不對。索引生效與否執(zhí)行計劃說了才算。MySQL 里在 SQL 前面加個 EXPLAIN 關(guān)鍵字就能看到執(zhí)行計劃EXPLAIN SELECT s.sname, sc.score FROM sc JOIN student s ON s.sno sc.sno WHERE sc.cno C001 AND sc.score 90;執(zhí)行計劃里重點看幾列。type 這一行最好不是 ALLALL 就是全表掃描說明索引沒起作用key 列顯示用到了哪個索引是 NULL 就說明沒用到rows 是預(yù)估掃描的行數(shù)數(shù)字越小越好Extra 出現(xiàn) Using filesort 說明排序在內(nèi)存里額外做了通常意味著索引沒能支持排序。有一個終極經(jīng)典的坑對索引列做函數(shù)運算。比如WHERE YEAR(enroll_year) 2023哪怕你在 enroll_year 上建了索引執(zhí)行計劃照樣給你全表掃描。原因是數(shù)據(jù)庫沒法對一列做完函數(shù)后的結(jié)果直接走索引必須把每一行的值都算一遍才知道合不滿足。正確的寫法是寫成范圍條件WHERE enroll_year BETWEEN 2023-01-01 AND 2023-12-31我自己的習(xí)慣是實驗里每驗證一個索引都把 EXPLAIN 的結(jié)果截圖存好然后寫一句“從執(zhí)行計劃可以看到key 從 NULL 變成了 idx_sc_cno_scorerows 從 XXX 降到了 YYY驗證了索引生效”。這句話寫下來老師很清楚你是真的理解而不是只會敲代碼。4. 存儲過程、事務(wù)與觸發(fā)器把業(yè)務(wù)邏輯寫進數(shù)據(jù)庫4.1 存儲過程的參數(shù)、變量與異常處理存儲過程本質(zhì)上就是把一段業(yè)務(wù)邏輯封裝在數(shù)據(jù)庫端需要的時候 CALL 一下就行。實驗里我會做一個“按學(xué)號和課程號修改成績”的存儲過程它比裸寫一條 UPDATE 多了一層價值能校驗記錄是否存在能在出錯時回滾還能返回處理結(jié)果。DELIMITER // CREATE PROCEDURE sp_update_score( IN p_sno CHAR(9), IN p_cno CHAR(4), IN p_new_score DECIMAL(5,2), OUT p_message VARCHAR(100) ) BEGIN DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN ROLLBACK; SET p_message 更新失敗已回滾; END; START TRANSACTION; UPDATE sc SET score p_new_score WHERE sno p_sno AND cno p_cno; IF ROW_COUNT() 0 THEN SET p_message 記錄不存在已回滾; ROLLBACK; ELSE COMMIT; SET p_message 更新成功; END IF; END // DELIMITER ;先說 DELIMITER 這個看起來很怪的東西?？蛻舳四J用分號作為一條語句的結(jié)束標志而存儲過程內(nèi)部每一行 UPDATE 后都有分號如果不臨時把分隔符改掉客戶端會在第一個分號處把“語句”斷開后面全部報錯。所以我先把分隔符改成 //等整個存儲過程體結(jié)束再用 // 收尾最后再改回分號。這個細節(jié)十個報錯的同學(xué)有八個是因為它。再講異常處理DECLARE EXIT HANDLER FOR SQLEXCEPTION 是這份代碼的靈魂。沒有它事務(wù)中途遇到約束沖突或語法錯誤時已經(jīng)執(zhí)行的語句不會自動回滾數(shù)據(jù)可能處于“改了一半”的狀態(tài)。有了它一旦捕獲異常就整體 ROLLBACK保證原子性。這個模式的行業(yè)里叫“先聲明異常哨兵再開啟事務(wù)”熟練掌握后寫任何數(shù)據(jù)修改類存儲過程都能套用。還有一點容易被忽略參數(shù)類型要和表字段完全一致。有一次我見同學(xué)把 p_new_score 聲明成 INT調(diào)用后傳 95.5結(jié)果誤差悄悄就出現(xiàn)了因為數(shù)據(jù)庫把 95.5 轉(zhuǎn)成了 96 再做更新。這種“看起來沒問題數(shù)據(jù)卻變了”的 bug 最折磨人提前聲明成 DECIMAL(5,2) 就不會有這回事。4.2 事務(wù)隔離級別與并發(fā)問題的復(fù)現(xiàn)事務(wù)的 ACID 四個特性背概念容易真正理解要靠動手。實驗要求里通常有一條是“演示并發(fā)環(huán)境下事務(wù)的隔離性”這里我給一個實際可操作的流程模擬兩個客戶端同時處理同一門課的選課人數(shù)。假設(shè)課程容量只剩 1 個名額兩個學(xué)生同時選課。如果不加鎖兩個事務(wù)都先查“剩余名額”都看到 1都執(zhí)行成功最后容量變成 -1這就叫超賣。解決辦法是查詢名額時加一把行鎖START TRANSACTION; SELECT quota FROM course WHERE cno C001 FOR UPDATE; -- 業(yè)務(wù)判斷剩余名額是否大于 0 UPDATE course SET quota quota - 1 WHERE cno C001; COMMIT;FOR UPDATE 的作用是把這一行鎖住第二個事務(wù)同樣執(zhí)行這條 SELECT 時會阻塞住直到第一個事務(wù) COMMIT 或 ROLLBACK它才讀到最新的剩余名額。這個過程不親手跑一遍很難體會“鎖”的含義。隔離級別是另一個高頻考點我建議畫一張表來記讀未提交會有臟讀和幻讀讀已提交能防臟讀但仍有不可重復(fù)讀和幻讀可重復(fù)讀防了前兩者但可能幻讀串行化全防但并發(fā)性能最差。MySQL 8.0 默認是可重復(fù)讀。實驗里復(fù)現(xiàn)這些并發(fā)問題有一個技巧在兩個會話里手動控制提交時機而不是讓程序瞬間跑完。比如在事務(wù)里故意加上 SELECT SLEEP(5); 模擬業(yè)務(wù)處理時間然后趁這個窗口在另一個會話里去讀同一條數(shù)據(jù)就能清楚觀察到另一個事務(wù)到底看到的是舊值還是新值。這個方法很土但非常有效比純講理論直觀得多。4.3 觸發(fā)器的適用場景與邊界觸發(fā)器最有價值的使用場景是那些“不管從哪個入口改數(shù)據(jù)都必須伴隨發(fā)生”的邏輯。成績修改審計就是一個標準例子不管成績是被哪個應(yīng)用、哪個用戶改的都必須留下一條審計記錄。寫代碼的人可能忘了寫日志但觸發(fā)器不會忘。CREATE TABLE score_audit ( id INT AUTO_INCREMENT PRIMARY KEY, sno CHAR(9) NOT NULL, cno CHAR(4) NOT NULL, old_score DECIMAL(5,2), new_score DECIMAL(5,2), op_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TRIGGER trg_score_audit AFTER UPDATE ON sc FOR EACH ROW BEGIN INSERT INTO score_audit(sno, cno, old_score, new_score) VALUES (OLD.sno, OLD.cno, OLD.score, NEW.score); END;AFTER UPDATE 表示行更新完成后觸發(fā)OLD 和 NEW 分別代表更新前、更新后的行。觸發(fā)器里把舊分和新分都寫進審計表事后想查“誰把成績從 58 改成了 88”一條 SELECT 就查出來了。但觸發(fā)器這個東西必須克制。我在實際項目中見過不少“觸發(fā)器災(zāi)難”有人為了讓系統(tǒng)自動同步某張表在表 A 的觸發(fā)器里更新表 B表 B 又有觸發(fā)器更新表 A結(jié)果形成循環(huán)調(diào)用數(shù)據(jù)庫直接報錯或者死鎖。實驗要求做一個觸發(fā)器就夠了千萬別為了炫技做過度的級聯(lián)設(shè)計翻車率非常高。還有一點要注意同一張表的 AFTER UPDATE 觸發(fā)器里如果再更新同一張表MySQL 會報遞歸觸發(fā)錯誤ERROR 1442。原因是 AFTER 階段行的最終狀態(tài)已經(jīng)確定了不允許再改動這張表。如果確實要修改應(yīng)該用 BEFORE 觸發(fā)器直接改 NEW 字段或者把邏輯挪到存儲過程里做。5. 常見問題與排查技巧實錄5.1 中文亂碼字符集問題亂碼是實驗四里出現(xiàn)頻率最高的問題沒有之一尤其在一開始建庫的時候就沒管字符集的情況下。亂碼的本質(zhì)是“寫入用的編碼”和“讀取用的編碼”不一致。我用中文“實驗”兩個字舉例如果服務(wù)器按 utf8mb4 存客戶端卻按 GBK 解讀每個中文字符的字節(jié)序列拆開再拼起來就變成了完全不通的字符。排查步驟很簡單。第一步看建庫語句有沒有指定字符集沒有的話執(zhí)行下面的命令看當(dāng)前是什么SHOW VARIABLES LIKE character_set_%;第二步看客戶端連接設(shè)置DBeaver 或 Navicat 里連接配置都有字符集選項統(tǒng)一選 utf8mb4。第三步看表的字符集SHOW TABLE STATUS LIKE student;能看到默認字符集。三處一致亂碼就消失了。我見過很多“查了很多方法都沒用”的案例最后都是因為連接串里沒指定 characterEncodingutf8卡了半天才解決。5.2 觸發(fā)器遞歸和死鎖觸發(fā)器相關(guān)的報錯里ERROR 1442 是最典型的一種。場景通常是同學(xué)想“成績更新后順手把總分表也更新了”于是在 sc 表的 AFTER UPDATE 觸發(fā)器里寫了 UPDATE sc 的語句結(jié)果直接報錯。原因前面說過AFTER 階段不能再改這張表本身。死鎖則是并發(fā)場景的高發(fā)問題。最常見的死鎖原因是兩個事務(wù)以不同順序加鎖事務(wù) A 先鎖成績表再鎖課程表事務(wù) B 先鎖課程表再鎖成績表雙方各拿一把鎖等對方釋放誰也等不到數(shù)據(jù)庫檢測到后主動把其中一個事務(wù)回滾釋放資源。排查死鎖有一個萬能命令SHOW ENGINE INNODB STATUS;輸出里找到 LATEST DETECTED DEADLOCK 段落能看到兩個事務(wù)各自持有哪些鎖、在等待哪個鎖據(jù)此就能調(diào)整加鎖順序。生產(chǎn)中避免死鎖的核心原則就是“所有事務(wù)按照相同的順序訪問表和行”這個原則做實驗的時候同樣適用。5.3 索引失靈的幾類典型場景很多同學(xué)跑完對比實驗發(fā)現(xiàn)“建了索引和沒建一樣慢”第一反應(yīng)是數(shù)據(jù)庫有問題其實十有八九是查詢寫法把索引廢了。最常見的幾類對索引列套函數(shù)比如 YEAR(create_time) 2023前面已經(jīng)說過隱式類型轉(zhuǎn)換比如索引列是 VARCHAR條件里寫 WHERE sno 20230001沒加引號數(shù)據(jù)庫會先把列轉(zhuǎn)成數(shù)值再比較索引同樣失效前導(dǎo)模糊查詢LIKE %張三% 無法利用索引因為索引樹是按前綴組織的而 LIKE 張三% 可以在索引列上用 OR 連接了兩個非索引條件優(yōu)化器權(quán)衡后可能直接放棄索引。這些場景每一條都可以在實驗里做個小驗證建索引 → 用失效寫法跑 EXPLAIN → 看 key 列變?yōu)?NULL → 改用正確寫法 → 看 key 列恢復(fù)。把這組對比寫進報告你整篇實驗報告的專業(yè)程度立刻上一個臺階。5.4 常見問題速查表現(xiàn)象可能原因解決辦法插入中文數(shù)據(jù)后顯示亂碼庫表字符集或客戶端連接編碼不一致統(tǒng)一使用 utf8mb4檢查連接配置存儲過程 CALL 報語法錯誤未用 DELIMITER 修改分隔符將分隔符臨時改為 // 再創(chuàng)建事務(wù)執(zhí)行一半報錯后數(shù)據(jù)沒變?nèi)碑惓Ｌ幚砥魑椿貪L聲明 EXIT HANDLER FOR SQLEXCEPTION觸發(fā)器執(zhí)行報 ERROR 1442AFTER 觸發(fā)器內(nèi)更新了同一張表改為 BEFORE 改 NEW或把邏輯搬到存儲過程建了索引 EXPLAIN 仍是全表掃描對索引列做了函數(shù)運算或類型轉(zhuǎn)換改寫為范圍條件或統(tǒng)一類型再比較兩個會話互相等鎖超時加鎖順序不一致統(tǒng)一事務(wù)內(nèi)的表訪問順序視圖查出來的數(shù)據(jù)少了誤用了 INNER JOIN 導(dǎo)致無選課記錄被丟改用 LEFT JOIN 保留主表全量6. 實驗報告怎么寫才能拿高分6.1 驗收時老師到底在看什么實驗四的驗收和前面幾次有很大區(qū)別前面可能看結(jié)果有沒有跑出來到實驗四更看重的是一句話“你能不能講清楚為什么”。我自己參與過幾次驗收老師常問的問題大致就這幾類第一你這個視圖解決的是什么問題它和直接寫長 SQL 有什么區(qū)別第二你的索引為什么選這幾個字段建EXPLAIN 給你什么信息第三存儲過程里為什么要用事務(wù)沒有事務(wù)會怎樣第四觸發(fā)器為什么不用存儲過程替代兩者的邊界在哪。這些問題全部指向“理解”而不是“代碼能跑”。所以準備驗收的時候別背代碼背邏輯。把每個知識點對應(yīng)的業(yè)務(wù)場景、為什么選這個手段、效果怎么驗證這三件事理順老師問什么你都能從場景出發(fā)講清楚。6.2 報告結(jié)構(gòu)與加分寫法報告結(jié)構(gòu)我建議按這個順序組織實驗?zāi)康?→ 實驗環(huán)境 → 需求與整體設(shè)計 → 表結(jié)構(gòu)和數(shù)據(jù)說明 → 各知識點實現(xiàn)過程 → 對比實驗與結(jié)果分析 → 遇到的問題與解決 → 實驗心得。前兩部分控制在半頁以內(nèi)別寫廢話。需求與整體設(shè)計部分把“為什么選成績管理場景、五個知識點怎么串起來”講明白這部分是拉開分數(shù)的第一個機會。各知識點實現(xiàn)部分代碼要完整運行結(jié)果要有截圖關(guān)鍵操作要有執(zhí)行計劃這是拉開分數(shù)的第二個機會。對比實驗是最大的加分項。無索引和有索引的查詢耗時對比、不同隔離級別下并發(fā)讀的結(jié)果對比、不帶異常處理和帶異常處理的存儲過程執(zhí)行對比這三組對比只要做了報告的分析深度立刻和別人的“代碼堆砌”拉開距離。我自己常看到一個有意思的現(xiàn)象同樣兩個知識點都完成了的同學(xué)寫對比實驗的人普遍比只貼代碼的人分數(shù)高一截。還有一個細節(jié)報告里的每個截圖都要配一兩句解釋說明“從這張圖能看到什么、結(jié)果驗證了什么”。只貼圖不解釋等于沒貼解釋了才證明圖里的信息你真的看懂了。寫在最后這套實驗做完我最大的感受是它把數(shù)據(jù)庫從“存數(shù)據(jù)的地方”變成了“幫你把數(shù)據(jù)管好的工具”。以前寫一條 UPDATE 我從不考慮后果現(xiàn)在看到任何對數(shù)據(jù)的修改腦子里會自動彈出三個問題要不要包事務(wù)、要不要留審計、要不要控制并發(fā)。這個思維習(xí)慣比記住那些 SQL 語法值錢得多。最后分享一個小技巧實驗做完之后把全部腳本從頭到尾重新執(zhí)行一遍完全模擬助教驗收現(xiàn)場。這一步能提前暴露九成以上的意外問題——視圖建錯順序、觸發(fā)器重復(fù)創(chuàng)建、樣本數(shù)據(jù)沒清理干凈全是這種“平時感覺沒事、驗收突然爆炸”的隱藏雷。在宿舍里先爆掉總比在老師面前爆掉體面這個道理做多了實驗自然就懂了。