lower_case_table_names=1必须在首次初始化前设置，因其为启动时读取的只读参数，运行中不可修改；若数据目录已存在，修改后重启将因磁盘文件名与元数据不匹配而启动失败。
lower_case_table_names=1 为什么必须在初始化前设置
因为 lower_case_table_names 是 MySQL 启动时读取的系统级参数，不是运行时变量。你用 SET GLOBAL lower_case_table_names = 1 会直接报错：Variable 'lower_case_table_names' is a read-only variable。它决定表名如何写入磁盘、如何解析 SQL、如何匹配元数据——三者必须一致，否则启动阶段就校验失败。
常见错误现象：已有表 UserLog（磁盘上是 UserLog.frm），改配置为 1 后重启，MySQL 找不到 userlog.frm，直接报错 Table 'xxx.UserLog' doesn't exist，服务无法启动。
- Linux 上新装实例默认值是
0，Windows/macOS 默认是1或2 - 如果已有数据且含大写字母表名，唯一安全路径是：停库 →
mysqldump --all-databases导出 → 删除datadir下所有文件（除mysql系统库外）→ 修改配置 →mysqld --initialize或启动初始化 → 再导入 - 别信“用
RENAME TABLE UserLog TO userlog补救”的方案：它只改INFORMATION_SCHEMA，不改磁盘文件名，在lower_case_table_names=1下反而导致字典不一致
my.cnf 里加 lower_case_table_names=1 却不生效？检查这三点
最常踩的坑是配置位置错、格式错、服务没真正重启。Linux 下常见配置路径是 /etc/my.cnf 或 /etc/mysql/my.cnf，Windows 是 C:\ProgramData\MySQL\MySQL Server 5.7\my.ini。
必须确认：
-
lower_case_table_names=1必须放在[mysqld]段内，不能在[client]或全局段；放错位置会导致 MySQL 完全忽略该配置 - 配置文件保存编码：Windows 上用记事本编辑
my.ini时，必须选“ANSI”编码保存，UTF-8 BOM 会导致服务启动失败 - 重启命令是否真生效：执行
systemctl restart mysqld后，用ps aux | grep mysqld看进程时间戳是否更新；若提示Unit not found，先查真实服务名：systemctl list-unit-files | grep mysql或ls /etc/init.d/ | grep -i mysql
验证 lower_case_table_names 是否已生效
重启后登录 MySQL，直接运行：
SHOW VARIABLES LIKE 'lower_case_table_names';
返回值必须是 1。再建一张测试表验证行为：
- 执行
CREATE TABLE TestUser (id INT) - 用
SHOW TABLES查看，显示的是testuser（小写） - 然后试
SELECT * FROM TESTUSER、SELECT * FROM testuser、SELECT * FROM TestUser—— 全部应成功 - 若其中任一失败，说明参数未生效或存在残留旧表干扰
注意：lower_case_file_system 显示 OFF 是正常的（Linux 文件系统本身区分大小写），它不影响 lower_case_table_names 的行为。
应用部署时仍报 Table doesn't exist？排查大小写源头
即使 lower_case_table_names=1 生效，应用仍可能因 SQL 中硬编码大小写不一致而失败。比如 ORM 配置里写 table_name: "UserProfile"，但数据库里实际是 userprofile，某些驱动（尤其老版本 PDO）会保留原始字符串传给 MySQL，触发匹配逻辑异常。
- 统一开发规范：建表语句全部用小写，如
CREATE TABLE users，而非Users或USERS - Docker 部署时，在
my.cnf固定写死lower_case_table_names=1，并把初始化 SQL 脚本也全小写，避免依赖宿主机默认值 - 检查连接字符串和查询模板：PHP 中避免
"SELECT * FROM {$prefix}Users"，改用"SELECT * FROM {$prefix}users" - 备份恢复场景下，确保
mysqldump输出的 SQL 文件中表名也是小写（默认就是，除非用了--skip-extended-insert等非常规选项）
真正麻烦的从来不是改参数，而是已有混合大小写的表名和跨平台迁移时的隐性不一致——这些不会报错，但会在某次上线后突然找不到表。
