MySQL表名是否区分大小写由lower_case_table_names参数决定，其值为0（严格区分）、1（不区分）或2（仅非Linux有效），该参数需在初始化前配置且不可动态修改。
MySQL 表名是否区分大小写，完全由 lower_case_table_names 参数决定，且该参数不可动态修改——必须在 MySQL 初始化前配置，重启后生效。
怎么查当前的大小写规则？
直接连上 MySQL 执行：
SELECT @@lower_case_table_names;
或
SHOW VARIABLES LIKE 'lower_case_table_names';
返回值只有 0、1、2 三种可能：
-
0：严格区分大小写（Linux 默认，建表名怎么写就怎么存，查询也必须完全匹配） -
1：不区分大小写（Windows/macOS 默认，所有表名强制转小写存储和匹配） -
2：仅在非 Linux 系统有效，建表保留原大小写，但查询时转小写匹配（Linux 上设为 2 会被忽略，实际按 0 处理）
想改成不区分大小写（推荐生产用），必须满足两个硬条件
很多人改完配置重启失败，就是因为跳过了这两步：
- 配置必须加在
my.cnf的[mysqld]段下，例如：lower_case_table_names = 1 -
已有数据的实例不能直接改：MySQL 8.0+ 初始化后禁止修改该参数；5.7 虽允许改，但若磁盘上已存在大写表名（如
UserLog.frm），重启后这些表会“消失”——SHOW TABLES看不见，SELECT FROM UserLog报错Table 'xxx' doesn't exist
正确做法只有一条路：停机导出全库（mysqldump --all-databases），清空 datadir，修改配置，再初始化并导入。
误建了大写表名，临时救急怎么办？
如果只是个别表命名不规范（比如 CREATE TABLE MyUser），又不想停机，可用 RENAME TABLE 手动转小写：
RENAME TABLE MyUser TO myuser;
注意：
- 必须逐个执行，不能批量（MySQL 不支持通配符重命名）
- ORM、SQL 脚本、备份文件里所有引用该表的地方，都得同步改成小写，否则运行时仍会报错
- 执行后立刻验证：
SHOW CREATE TABLE myuser;确认表结构无损
为什么统一用小写表名是最省事的方案？
跨平台迁移、团队协作、ORM 自动生成、CI/CD 自动化部署——所有环节都依赖表名一致性。哪怕你只在 Linux 上跑，只要代码里混用 User 和 user，早晚会在某次部署或恢复 dump 时卡住。
真正容易被忽略的点不是参数怎么写，而是：**lower_case_table_names 只管表名，不管列名或 SQL 关键字；列名大小写是否敏感，取决于字段定义时是否加 BINARY 或使用 utf8_bin 排序规则——这是另一个维度的问题，别混在一起调。**
