MySQL 大小寫敏感性規則與跨平台避坑指南

MySQL 識別符 (庫/表/欄位/別名/變量) 大小寫敏感性由作業系統檔案系統與配置參數 lower_case_table_names 共同決定，Linux 區分、Windows 不區分，跨平台遷移極易踩坑。

各平台預設規則

根本原因

• MySQL 將庫/表對應為檔案系統目錄/檔案，Linux (ext4/xfs) 區分大小寫，Windows (NTFS) 不區分、macOS (APFS/HFS+) 預設不區分。
• 欄位/別名/變量在記憶體中比較，預設使用 utf8_general_ci 等 _ci (Case Insensitive) 排序規則，故不區分大小寫。
• 編譯時預設字符集 latin1/ISO-8859 不區分大小寫，影響早期版本行為。

控制參數：lower_case_table_names

⚠️ 關鍵限制： lower_case_table_names 只能在 初始化資料目錄前 設定 (mysqld --initialize 前)，運行中修改需重新初始化 (相當於重裝)，生產環境極其謹慎。

實戰踩坑案例

-- Linux 環境
CREATE DATABASE swxx_zxwd;
CREATE DATABASE SWXX_ZXWD;  -- 成功建立兩個不同庫！

SELECT * FROM swxx_zxwd.table1;  -- 查庫1
SELECT * FROM SWXX_ZXWD.table1;  -- 查庫2，結果完全不同！

手抖建立同名不同大小寫庫/表，SQL 查詢時大小寫決定訪問哪個對象，極易導致資料不一致、應用邏輯錯亂。

解決方案與最佳實踐

1. 規範源頭： 開發規範強制 全小寫 + 下劃線，庫/表/欄位/索引/別名/變量無一例外。
2. Linux 生產環境保持 0： 利用檔案系統天然區分特性，及時發現命名衝突。
3. Windows/macOS 開發環境設 1： my.ini [mysqld] 加 lower_case_table_names=1，模擬生產不區分行為，避免開發期建立大小寫差異對象。
4. 字段值需區分大小寫： 欄位定義加 BINARY 屬性或用 VARBINARY 類型，或查詢時 WHERE BINARY col = 'Abc'。
5. 遷移檢查腳本： 上線前掃描 INFORMATION_SCHEMA 發現大小寫衝突：

   SELECT TABLE_SCHEMA, TABLE_NAME, COUNT(*) 
   FROM INFORMATION_SCHEMA.TABLES 
   GROUP BY LOWER(TABLE_SCHEMA), LOWER(TABLE_NAME) 
   HAVING COUNT(*) > 1;
   

排序規則對字符串比較的影響

• _ci (Case Insensitive)：'A' = 'a'，預設如 utf8_general_ci、utf8mb4_0900_ai_ci
• _cs (Case Sensitive)：'A' != 'a'，如 utf8_bin、utf8mb4_0900_as_cs
• _bin：二進位比較，最快、嚴格區分大小寫、不支援多語言排序規則

查詢欄位排序規則：SHOW FULL COLUMNS FROM tbl; 或 SELECT COLLATION_NAME FROM INFORMATION_SCHEMA.COLUMNS ...

大小寫敏感性是跨平台 MySQL 部署的「隱形殺手」，統一小寫命名規範 + 環境參數對齊 + 遷移前掃描，三重保險消除風險。