mysql 8.0 的 lower_case_table_names 是启动级只读参数，初始化后无法修改；linux 默认为0（区分大小写），要实现不区分需重建实例并重导数据。
MySQL 8.0 为什么改了 lower_case_table_names 也无效
因为这个参数是只读的，必须在初始化实例前就设好，启动后无法动态修改。哪怕你进 MySQL 执行 SET GLOBAL lower_case_table_names = 1，也会报错 Variable 'lower_case_table_names' is a read only variable。它不是普通系统变量，而是影响数据字典底层存储逻辑的启动级配置。
常见错误现象：
– 修改了配置文件重启，表名还是区分大小写
– SHOW VARIABLES LIKE 'lower_case_table_names' 显示值没变
– 创建的表 User 和 user 能同时存在（说明实际生效的是 0）
- Linux 下默认值是
0；macOS（使用 APFS）默认是2；Windows 是1 - 如果数据目录里已有表文件（
.ibd或.frm），直接改配置重启会失败或导致实例无法启动 - MySQL 8.0+ 使用数据字典表（
mysql.schemata,mysql.tables），表名存储方式和该参数强绑定，不一致会引发元数据损坏
想让 Linux 上的 MySQL 表名不区分大小写，只能重建实例
这不是“配一下就能行”的事，本质是重做整个数据字典。如果你的库还很新、数据量小，建议导出再导入；已有生产数据，得停机操作。
关键步骤：
- 用
mysqldump --all-databases --single-transaction > full.sql导出全部数据（注意：不能用--skip-triggers等漏结构的选项） - 彻底停止 MySQL，删除原
datadir（如/var/lib/mysql），确保清空 - 在
my.cnf的[mysqld]段加上lower_case_table_names=1，且确认没有其他冲突配置（如innodb_file_per_table=OFF可能干扰） - 用
mysqld --initialize --user=mysql重新初始化实例（别跳过这步！否则字典不兼容） - 启动 MySQL，再用
mysql 导入
注意：lower_case_table_names=1 后，所有表名在磁盘上都以小写存储，SQL 中无论写 SELECT * FROM USER 还是 user 都能命中——但建表语句里的名字会被强制转小写存入数据字典。
lower_case_table_names=2 是什么场景用的
这是 macOS 默认值，适用于文件系统本身不区分大小写（比如 APFS、HFS+），但 MySQL 内部仍保留原始大小写显示。它只做“映射”，不改变存储形式。
使用场景有限：
– 开发环境跑在 Mac 上，又需要和 Linux 生产环境保持 SQL 习惯一致（比如写 CREATE TABLE User 不想被自动转成 user）
– 不想重建实例，又希望避免因大小写导致的 Table doesn't exist 错误
- 它不能解决跨平台迁移时的大小写冲突问题（比如从 Linux
lower_case_table_names=0导出的 dump，在 Mac 上=2导入后，User和user仍可能撞名） - 性能无影响，但要注意：
INFORMATION_SCHEMA.TABLES.TABLE_NAME返回的是原始建表名，而磁盘文件名仍是小写，排查问题时容易混淆 - MySQL 8.0.17+ 要求
lower_case_table_names=2时必须搭配innodb_file_per_table=ON，否则启动失败
应用层绕过这个问题最现实的办法
别指望靠数据库参数一劳永逸。绝大多数业务出问题，不是因为参数没设对，而是代码里硬写了大小写混用的表名，或者 ORM 自动生成了不一致的引用。
- 统一用小写字母 + 下划线命名表（如
user_profile），在建库脚本、Flyway/Liquibase 迁移、ORM 映射配置里全部锁定 - 检查所有 SQL 字符串拼接点，禁止用变量插表名（
"SELECT * FROM " + tableName）——这是大小写问题的高发地 - 开发机用 Docker 跑一个和生产一致的 MySQL 镜像（比如
mysql:8.0+ 自定义my.cnf），避免本地 Mac 和测试 Linux 环境行为不一致
真正麻烦的从来不是参数本身，而是已有 N 个服务、M 个脚本、几十万行 SQL 里散落的大小写假设。改库不如先锁住命名规范。
