怎麼搬個家就崩了？MySQL 大小寫敏感性解析

「資料庫名稱只差一個大寫，整個服務就爆了。」

在軟體開發的世界裡，環境一致性一直是開發者心中的痛。今天要分享的是一個真實發生的 MySQL 大小寫敏感性案例，這個問題看似微小，卻能在關鍵時刻讓整個系統崩潰。

分享目標

• 分享真實的 MySQL 大小寫問題案例
• 深入理解 MySQL 大小寫敏感性的成因
• 提供實用的防範建議與最佳實務

真實案例：只是搬個家，怎麼就崩了？

情境描述

• 原本 Dev 環境在 On-Premise（地端） ，準備升級搬遷到 EKS 雲端 (AWS)
• DBA 成功把 DB 從地端 migrate 到雲端
• 所有人以為萬事OK，直到——
• 服務突然整個壞掉，部份API 爆炸

問題根源

開始 Debug 後發現：

• On-Premise（地端）的 DB 名為 example_db
• tw-ekd-dev 環境雲端 DB 名為 example_db
• 但 Production 的 DB 名為 Example_db（首字大寫）

爆炸原因

Code 裡有：Example_db.some_table.some_column

在 Linux + MySQL 大小寫敏感的情況下，dev 找不到這個 DB，直接爆炸。

為什麼要在意？

這些問題在開發過程中經常被忽略：

• Windows 測試沒事，Linux production 查不到資料？
• alias 名稱取錯大小寫，導致 ORM 找不到欄位？

各層級是否敏感？

為什麼 MySQL 資料庫名稱會因作業系統而大小寫敏感？

MySQL 資料表與資料庫是以檔案儲存

MySQL 並非把所有資料寫入單一檔案，而是：

• 每個 資料庫 → 一個資料夾
• 每個 資料表 → 對應一組檔案（如 .frm, .ibd, .MYD 等）

實際範例：

已複製！
/var/lib/mysql/
  ├── mydb/
  │    ├── users.ibd
  │    ├── orders.ibd

OS 檔案系統對大小寫的敏感性

所以：MySQL 把資料表對應為檔案後，是否區分大小寫，就「由檔案系統決定」。

MySQL 的 lower_case_table_names 設定

這個參數用來統一 MySQL 對資料表名稱、資料庫名稱的處理方式：

示範與實驗建議

可以進行以下測試來驗證環境差異：

已複製！
-- 測試資料表大小寫
CREATE TABLE Users (
    id INT PRIMARY KEY,
    name VARCHAR(50)
);

-- 在不同環境測試
SELECT * FROM Users;   -- 可能成功或失敗
SELECT * FROM users;   -- 可能成功或失敗

實務建議

設定層面

• 本地與上線請一致設 lower_case_table_names = 1
• 在 Docker 或測試環境中也要模擬 production 的設定

命名規範

• 清楚標註資料庫／資料表／欄位命名慣例
• 建議統一使用小寫命名，避免大小寫混用
• 在團隊文件中明確記錄命名規則

資料比對

• 針對有意義的比對（如帳號、email），指定明確 collation
• 區分「顯示用」與「比對用」的字串處理策略

小結

• 資料庫的大小寫敏感性源自於檔案系統的特性
• 不同作業系統會導致完全不同的行為
• 明確設定 lower_case_table_names 是避免問題的關鍵
• 環境一致性比任何技巧都重要

延伸閱讀

• MySQL Case Sensitivity Overview
• MySQL Identifier Case Sensitivity
• 可搭配 docker-compose 模擬不同設定環境做測試

Q&A

你曾遇過：

• 資料表大小寫問題導致 ORM crash？
• 在不同環境中出現「找不到資料表」的錯誤？
• 因為作業系統差異導致的資料庫問題？

歡迎在下方留言分享你的經驗！