🕵️ 資料庫與 PHP 資深工程師面試：你掉進「陷阱題」了嗎？

作為資深架構師，我整理了這份面試中常見的陷阱題清單。這些問題的目標不是測試知識廣度，而是深入檢驗你對系統細節、工程權衡與風險邊界的掌握。如果你只會背誦答案，將會露出破綻。

一、 精度與型別：浮點陷阱與資料正確性

1. 題目：WHERE price = 0.1，能找到 DECIMAL(10,2) 與 DOUBLE 存的值嗎？為什麼？

面試官想測什麼？	理想回答要點	紅旗警告 (Red Flag)
關鍵： 儲存型別的差異、浮點數近似儲存的理解、實際業務場景（金額）的處理。	結論： DECIMAL 可以，DOUBLE 極可能失敗。細節： DECIMAL 採用精確的十進位儲存，故 0.1 就是 0.1。DOUBLE 採用二進位浮點數儲存，0.1 無法精確表示，儲存的是一個近似值（如 $0.10000000000000000555$），導致精確比對失敗。替代： 應用層所有金額運算都應使用 BCMath 或將金額整數化儲存（單位：分），DB 端必須使用 DECIMAL。	只回答「因為浮點不準確」，但沒有提到 DECIMAL 的正確性，也沒說明應用層的具體解決方案。

2. 題目：floor((0.7+0.1)*10) 在 PHP/MySQL/JS 結果是否相同？

面試官想測什麼？	理想回答要點	紅旗警告 (Red Flag)
關鍵： 跨語言/DB 環境下的浮點行為不一致性與四捨五入（Rounding） 的差異。	結論： 不盡相同，可能得到 7 或 8。細節： 在 PHP 標準浮點運算中 0.7+0.1 可能約等於 $0.7999999999999999$；乘以 10 再取 floor 會得到 7 (因為浮點數儲存偏差)。解決： 使用 PHP 的 BCMath 擴展進行高精度運算，或將其轉換為整數再運算，結果應為 8。DB 端的 DECIMAL 運算結果也是 8。	籠統地說「不相同」，但沒能具體說出 PHP 浮點運算可能產生的 7 這個錯誤結果，或沒有提到 BCMath。

---

二、 交易與鎖：死鎖、分佈式與一致性陷阱

3. 題目：在兩個資料庫連線分別執行 SELECT ... FOR UPDATE，會發生什麼？如何避免死鎖？

面試官想測什麼？	理想回答要點	紅旗警告 (Red Flag)
關鍵： 行鎖（Row Lock）、鎖順序（Lock Order）、死鎖偵測與重試機制的實戰理解。	結論： 可能發生 鎖等待，若兩事務交叉鎖定，則引發 死鎖（Deadlock）。細節： FOR UPDATE 是悲觀鎖，會阻止其他事務讀寫鎖定行。死鎖的唯一預防是確保所有事務以相同的順序鎖定資源（例如，總是先鎖 ID 小的行）。替代： 讓交易儘可能短；設置合理的重試機制（帶指數退避），並在重試前徹底回滾失敗交易。	只說「避免用 FOR UPDATE」；或只依賴重試，但沒說如何確保鎖順序一致。

4. 題目：跨多個資料表或服務的分散式交易如何實作？

面試官想測什麼？	理想回答要點	紅旗警告 (Red Flag)
關鍵： 對 兩階段提交（2PC） 複雜度與 最終一致性 實務權衡的掌握。	結論： 在微服務或跨庫場景，應採用 Saga 模式 實現最終一致性。細節： 描述 Saga 流程：將單一交易拆成一系列本地事務，透過 事件/消息隊列 串聯。如果任一本地事務失敗，則觸發補償交易回滾之前已完成的步驟。架構： 利用 消息系統（如 Kafka/RabbitMQ）確保事件的可靠傳輸，保證可恢復性。	只提 XA / 兩階段提交（2PC），忽略其在現代分散式系統中性能差、阻塞時間長、難以操作的現實問題。

---

三、 索引與查詢：優化與失效陷阱

5. 題目：為什麼加索引後某些查詢反而變慢？

面試官想測什麼？	理想回答要點	紅旗警告 (Red Flag)
關鍵： 索引的 I/O 成本、寫入成本、選擇性（Selectivity），以及 DB 統計資訊（Statistics） 的影響。	結論： 索引會帶來 寫入延遲（需要同時更新索引）和查詢 I/O 成本（優化器可能選擇錯誤計畫）。細節： 1. 寫入成本： 索引越多，INSERT/UPDATE/DELETE 越慢。2. 低選擇性： 如果索引欄位重複值過多（例如性別），優化器可能放棄使用索引，導致額外的 I/O 開銷。3. 優化器誤判： 統計資訊過期或不準確，導致優化器選擇全表掃描。解法： 使用 EXPLAIN 分析掃描行數；定期更新統計資訊。	只講「因為索引太多」，但不能提供具體的診斷工具（EXPLAIN）或判斷依據（選擇性、寫入延遲）。

6. 題目：有哪些情況下索引不會被用到？（舉例）

面試官想測什麼？	理想回答要點	紅旗警告 (Red Flag)
關鍵： 考核對 SQL 語句、函式與索引之間邊界條件的細節掌握。	結論： 索引失效通常是查詢條件破壞了索引的有序性或可比性。舉例： 1. 模糊查詢： LIKE '%keyword'（開頭使用通配符）。2. 隱式型別轉換： WHERE phone = 123 (若 phone 是字串型別)。3. 欄位上套用函式： WHERE YEAR(date_column) = 2024。4. 複合索引順序錯誤： 查詢條件未使用複合索引的前導欄位。優化： 應改寫查詢或建立覆蓋索引（Covering Index）。	只能列出 1-2 種情況，或沒說清楚隱式型別轉換的本質原因。

---

四、 遷移與治理：零停機與權衡陷阱

7. 題目：要把某欄位從 INT 換成 BIGINT，且資料量有 TB，如何做零停機遷移？

面試官想測什麼？	理想回答要點	紅旗警告 (Red Flag)
關鍵： 考核候選人對線上 DDL 工具、雙寫與風險控制的掌握。	結論： 絕不能直接 ALTER TABLE（會鎖表），必須使用線上 Schema 變更工具。細節： 採用如 pt-online-schema-change 或 gh-ost 的工具。原理是：1. 建立新表： 建立擁有新 Schema 的影子表。2. 雙寫/追趕： 在應用層實現雙寫（寫入舊表與影子表）；工具則負責回填（Backfill）舊表資料並透過 Binlog 實時同步增量數據。3. 原子切換： 最終透過原子性的 RENAME TABLE 完成切換。風險： 需全程監控複製延遲與主從負載。	單純建議停機，或只建議使用 ALTER TABLE 而未考慮到高併發下的表鎖問題。

8. 題目：為什麼有時要反正規化？會帶來哪些後果？

面試官想測什麼？	理想回答要點	紅旗警告 (Red Flag)
關鍵： 考核候選人對 讀/寫性能 Trade-offs、資料一致性維護成本 的理解。	結論： 反正規化的目的是提升讀取性能，以犧牲寫入與一致性維護成本為代價。情境： 適用於 報表、查詢成本高的 Join 或 讀取遠高於寫入 的情境（例如將用戶名快取到訂單表）。後果： 1. 資料冗餘： 儲存空間增大。2. 更新異常： 當原始資料更新時，所有冗餘的複本都需要同步更新，增加 寫入負擔 與 資料不一致 的風險。策略： 必須設計自動同步機制（如事件驅動）來維護資料一致性。	只單純說「讀取速度快」，但未說明如何維護冗餘資料的同步與一致性。

---

五、 安全、合規與運維：風險與成本陷阱

9. 題目：若法律要求刪除用戶資料，你怎麼在資料庫層面落實？

面試官想測什麼？	理想回答要點	紅旗警告 (Red Flag)
關鍵： 硬刪除 與 軟刪除（Soft Delete） 的權衡、備份快照的處理、以及合規性挑戰。	結論： 需採用 硬刪除（Hard Delete） 才能滿足合規要求，但必須分階段進行。流程： 1. 應用層 Soft Delete： 設定 deleted_at 欄位，停止服務存取。2. 後台 Hard Delete Job： 啟動一個低優先級的任務，根據外鍵與關聯關係，徹底清除相關資料。3. 備份處理： 最關鍵的是：必須確保未來的備份與長期保留的快照中不再包含該敏感資料。4. 審計： 記錄刪除請求與執行的完整日誌。	只講 Soft Delete，沒提到備份快照或異地複本仍可能保留敏感資料的合規風險。

10. 題目：RPO 1 小時、RTO 10 分鐘，你怎麼設計？

面試官想測什麼？	理想回答要點	紅旗警告 (Red Flag)
關鍵： 將 SLA 指標 轉化為 具體技術架構 的能力。	結論： RTO (恢復時間) 10 分鐘要求 自動化故障切換；RPO (資料丟失) 1 小時則要求備份/複製延遲小於 1 小時。架構： 1. RTO (10m)： 採用 主從複製，並搭配 自動 Failover 程式（如 Orchestrator, Patroni）與健康檢查，將切換時間控制在數分鐘內。2. RPO (1h)： 採用 異步複製 即可滿足（延遲遠小於 1 小時）。如果要求 RPO 趨近於零，則必須使用半同步/同步複製。關鍵： 必須有定期的災難恢復演練，並記錄每次演練的 RTO 紀錄。	只貼合工具名（如 RDS Multi-AZ）但沒有說明演練與驗證的重要性，或混淆了同步/異步複製的 RPO 差異。

11. 題目：為什麼雲端 DB 服務有時比自管貴，但你還會選擇自管？

面試官想測什麼？	理想回答要點	紅旗警告 (Red Flag)
關鍵： 檢視候選人對 成本（TCO）、控制權、合規 之間的商業與技術權衡。	結論： 選擇自管是為了極致的控制權、降低長期 TCO 或滿足特殊的合規要求。情境： 1. 性能調校： 需要對內核參數、作業系統層進行極度深度優化（例如，針對極高 I/O 或記憶體密集型場景），雲端託管服務無法滿足。2. 資料主權/合規： 某些金融/政府客戶要求資料必須放在特定實體機房。3. 長期成本： 當業務體量極大且增長趨緩時，自管可能透過自建硬體/優化授權，長期 TCO 低於雲端。	只單純回答「因為自管便宜/控制力強」，而不能給出具體的、不可替代的自管場景（例如：需要修改 DB 內核或 OS 層參數）。