MySQL 在 Windows 與 Linux 下表名大小寫敏感度差異解析

問題背景

在將本機 Windows 環境的資料庫表結構直接複製至 Linux 虛擬機後，專案啟動報錯：Table 'sdmqrt.QRTZ_LOCKS' doesn't exist。明明表存在，卻提示找不到。經排查發現，問題根源在於 MySQL 在不同作業系統下對表名大小寫的預設處理方式不同。

核心差異

為何會發生錯誤？

Windows 下建表時可能使用大小寫混合（如 QRTZ_LOCKS），MySQL 內部以小寫儲存。Linux 下查詢時若 SQL 寫死大寫表名，因檔案系統區分大小寫，會找不到對應的 .frm 檔案。Spring Quartz 等框架若在程式碼中硬編碼大寫表名，在 Linux 下即會失效。

解決方案

方案一：統一開發與生產環境設定（推薦）

在 Linux 的 /etc/my.cnf（或 /etc/mysql/my.cnf）的 [mysqld] 區段加入：

lower_case_table_names = 1

重啟 MySQL 服務後，表名將不區分大小寫，與 Windows 行為一致。注意： 此參數需在初始化資料目錄前設定，否則現有資料可能無法存取。

方案二：規範命名規範（根治）

• 所有資料庫、表名、欄位名統一使用小寫，單字以底線分隔（snake_case）。
• 應用程式與 ORM 框架配置映射時，明確指定表名為小寫。
• 避免在 SQL 語句中硬編碼大寫表名。

方案三：遷移時修正表名大小寫

若已有大量混合大小寫表名，可編寫腳本批次重命名：

RENAME TABLE `Old_Name` TO `old_name`;

最佳實踐建議

1. 開發環境模擬生產： 開發機同樣使用 Linux 或設定 lower_case_table_names=0，提早發現問題。
2. 版本控管結構腳本： 使用 Flyway、Liquibase 等工具管理結構變更，避免手工複製導致差異。
3. 檢查框架配置： Hibernate、MyBatis 等 ORM 確認 hibernate.physical_naming_strategy 或 mapUnderscoreToCamelCase 設定正確。

理解此差異並建立團隊命名規範，能有效避免跨平台部署的坑。