老闆的兩個問題，答案在同一處
一家八間分校、三千兩百名學員的補習班負責人丟來兩個問題：「表單多加一個『家長第二聯絡電話』，為什麼要三天？」「剛上線飛快，現在開學員列表要等八秒。」
兩題的答案都在資料庫：欄位決定資料長什麼樣，Migration 決定改它的代價，索引決定查得快不快，N+1 決定一個畫面要查幾次。
名詞一：資料表與欄位
一句話：資料表是固定格式的清冊，欄位是每一欄標題。
類比：Excel 活頁簿。一個工作表是一張資料表，最上面那排標題是欄位，每一列是一筆資料。差別是資料庫的欄位有身分證——型別、長度、可否空白、能否重複。
實例：這家補習班有 students、enrollments、payments、attendances 四張主表，點名表兩年累積到一百八十萬列。新欄位加在 students，但它不會只活在這張表。
名詞二：索引（Index）
一句話：索引是替欄位另做的排序目錄，讓資料庫不必翻遍整張表。
類比：圖書館索引卡櫃。沒卡片，館員得一排排翻；有按書名排序的卡片，三秒就指得出位置。MySQL 8.4 官方手冊說得直白：沒有索引就得從第一列掃完整張表，PostgreSQL 文件亦同。
實例：「家長報電話、查出哪位學員」沒索引要 3.2 秒，加索引後 0.04 秒。代價是佔空間、寫入要更新目錄，所以官方指南建議只加在真的會查詢或排序的欄位。
名詞三：Migration（版本遷移）
一句話：把每次結構改動寫成有順序、可重播、可回滾的腳本。
類比：裝潢改格局，每次改動都要留施工圖歸檔。你不會拿榔頭直接敲牆，而是畫圖、施工、驗收，再把圖留著——下一間分店照著蓋，出事時照著拆回去。Laravel 文件稱它為資料庫的版本控制。
實例：加那個欄位要寫 migration 腳本，在開發機、測試站、正式站各跑一次，並決定三千兩百筆舊資料填什麼；接著是表單、驗證、後台列表、匯出範本、月報表與 API。三天不是那一欄貴，是它牽動七處。
名詞四：N+1 查詢
一句話：該一次端上桌的東西，程式跑了幾十趟廚房。
類比：一桌十人點菜，服務生一次只端一盤，來回十一趟。程式也一樣：先查一次拿到五十位學員（「1」），再為每位各查一次主責老師（「N」）。
實例：那個八秒的列表一頁五十筆，每筆要顯示主責老師、在讀課程數、本月出席率，共 151 次查詢。改成整批撈回（eager loading）後降到 4 次，最大內容繪製時間從 8.1 秒掉到 1.4 秒，跨進LCP 良好標準 2.5 秒。這花了 6 小時。
四者的關係（概念圖）
腦中畫這張圖：左側四張橫向卡片是四張資料表，卡片頂端的小格子是欄位。卡片下方垂掛標著「索引」的書籤，只有掛書籤的欄位才有捷徑。最左邊編號 001、002、003 的時間軸，是 Migration 版本序列。右側應用程式有兩條線連向資料庫：一條粗線標「1 次批次查詢」，一束五十條細線標「N 次零散查詢」——細線束就是 N+1。
索引治單次查詢的快慢，修 N+1 治查詢的次數，只修一邊通常還是慢。
對預算、時程與風險的意義
以每小時 NT$1,200–1,800 估算：
- 純顯示的欄位：約 3–4 小時，NT$4,000–7,000。
- 會進報表與匯出的欄位：加上後台列表、匯出範本、月報表、API 與三環境部署，約 12–18 小時，NT$15,000–30,000，這就是「三天」。
- 補一組索引：約 3–5 小時，NT$4,000–9,000，投報率最高。
- 修一個 N+1：約 4–8 小時，NT$5,000–14,000；升級主機一年多付 NT$36,000–120,000 卻未必治到病根。
風險：沒有 Migration 紀錄，新團隊無法重建結構；沒有回滾腳本，尖峰停機一小時遠貴於省下的兩小時。
該問廠商的五個問題
- 「這個新欄位會影響哪幾張表、哪幾個畫面、哪幾支報表？請列清單。」
- 「結構改動有用 Migration 管理嗎？可以看檔案清單嗎？」
- 「上線出問題時回滾腳本在哪？要多久？資料會遺失嗎？」
- 「學員列表跑幾次查詢？有沒有 N+1？請給前後的次數與秒數。」
- 「最慢的三支查詢是哪幾支？缺哪些索引？加了寫入會慢多少？」
常見誤解：索引加越多越好
索引不是免費加速器，而是「用寫入速度與硬碟空間換讀取速度」的交易。在一天寫入幾千筆的點名表上亂加十幾個索引，讀取沒變快、寫入反而拖慢。
談需求前的自我檢查
- ☐ 知道新欄位會出現在哪些畫面與報表
- ☐ 確認廠商用 Migration 管理結構
- ☐ 問過回滾方式與所需時間
- ☐ 拿到最慢的三支查詢清單
常見問題 FAQ
多加一個欄位真的要三天？
若只在後台顯示、不進報表、不匯出、不走 API，3–4 小時就能完成。省錢關鍵是需求階段就講清楚要不要匯出、進不進報表。
為什麼資料越多越慢？當初測試很快啊？
測試環境只有幾十筆假資料，缺索引與 N+1 在這量級看不出來。驗收時就該用接近真實量體的資料壓測。
系統已經很慢，該先做哪一項？
順序是：抓慢查詢清單、補關鍵索引、修 N+1，最後才考慮加硬體。前兩項成本低、效果最明顯。
想知道你的系統慢在哪？
ScriptWalker 提供 30 分鐘免費技術諮詢：帶著你最慢的頁面來，我們當場告訴你那是缺索引、是 N+1，還是結構該重整。
- Email：[email protected]
- 電話：0916-224-047
- LINE：@ufv9089p