mysql 8.0 的 lower_case_table_names 在初始化时即固化进数据字典，不可运行时修改；任何 my.cnf 或 set global 修改均无效，重启会因 my-011087 错误失败，唯一安全方式是清空 datadir 后用 --lower-case-table-names=1 重新初始化。
MySQL 8.0 的 lower_case_table_names 不是“配不配得对”的问题，而是根本不能 runtime 修改——它在 mysqld --initialize 那一刻就写死进数据字典了，后续任何配置文件或启动参数改动都会被忽略。
为什么 SET GLOBAL 或 my.cnf 修改后 lower_case_table_names 仍无效
MySQL 8.0 用 InnoDB 数据字典统一管理元数据，表名、库名的大小写处理规则在初始化时就固化为一个不可变属性。你看到的 SELECT @@lower_case_table_names 返回值，可能是服务启动失败后 fallback 出来的默认值，不是真实生效状态。
-
SET GLOBAL lower_case_table_names = 1必报ERROR 1238：该变量只读，MySQL 明确拒绝运行时修改 - 编辑
/etc/my.cnf后重启失败？查日志，大概率出现[ERROR] [MY-011087] Different lower_case_table_names settings for server ('1') and data dictionary ('0') -
mysqld --verbose --help | grep lower_case显示的才是启动时实际采用的值，不是配置文件里写的那个
Docker 环境下首次启动必须用 --lower-case-table-names=1 参数
这是唯一能绕过“初始化即锁定”限制的方式：参数必须在 mysqld 第一次写入数据字典前就传进去。一旦容器生成过数据目录，再改配置或加参数都无效。
- 错误做法：
docker run启动容器生成数据卷 → 进容器改my.cnf→ 重启 → 必然报MY-011087 - 正确命令示例：
docker run -d --name mysql8 -e MYSQL_ROOT_PASSWORD=123 -v /data:/var/lib/mysql -p 3306:3306 mysql:8.0 --lower-case-table-names=1 - 若挂载了
conf.d/自定义配置，确保它没覆盖lower_case_table_names；Docker 启动参数优先级高于配置文件
已有数据目录时，lower_case_table_names=1 不是“开启”，而是“重建”
MySQL 8.0 不提供在线转换工具。所谓“设为 1 就兼容”，前提是所有表名在磁盘上已经是小写。停服务后检查 /var/lib/mysql/your_db/ 下的 .ibd 文件名：如果有 UserOrder.ibd、XXL_JOB_QRTZ.ibd 这类含大写字母的文件，说明数据字典记录的是模式 0。
- 安全路径只有两条：
– 全量导出：mysqldump --all-databases→ 清空/var/lib/mysql→ 用--lower-case-table-names=1重初始化 → 导入
– 或逐表RENAME TABLE `UserOrder` TO `userorder`，但必须同步改所有 SQL 引用、视图、存储过程、外键约束中的大小写 - 云数据库（如阿里云 RDS）通常已固定为 1，你只能改应用层 SQL，不能指望服务端适配你的大写表名
最容易被忽略的一点：Linux 上 lower_case_table_names=2 是官方明确不建议使用的值，InnoDB 在某些文件系统操作中会出错；生产环境只应选 0 或 1，且切换前必须确认所有 SQL 和 ORM 层已适配目标大小写规则。
