MySQL 8.0 在 Linux 上无法运行时修改 lower_case_table_names——该参数必须在首次初始化时通过 --lower-case-table-names=1 显式指定，否则数据字典固化为默认值 0，后续仅改配置文件会导致启动报错 MY-011087。
MySQL 8.0 在 Linux 上无法运行时修改表名大小写敏感性——lower_case_table_names 必须在初始化前设定，否则直接报错 MY-011087。
为什么改配置文件后重启 MySQL 会失败
你在 /etc/my.cnf 里加了 lower_case_table_names=1，但 MySQL 启动时报错：
2024-10-29T11:32:10.290204Z 1 [ERROR] [MY-011087] [Server] Different lower_case_table_names settings for server ('1') and data dictionary ('0').这是因为 MySQL 8.0 的数据字典（mysql.ibd、系统表空间）在初始化时就固化了该值，后续仅改配置文件无效。服务启动时发现磁盘上存的是 0（大小写敏感），而配置要 1（不敏感），直接拒绝启动。
- 该参数是只读的，
SET GLOBAL lower_case_table_names = 1会提示variable is a read-only variable -
mysqld --initialize不带--lower_case_table_names=1参数，就等同于用默认值0初始化 - 即使你删了
/var/lib/mysql但没在初始化命令里显式传参，仍会沿用默认行为
正确初始化：必须带 --lower_case_table_names=1 参数
停服务 → 清空数据目录 → 显式指定参数初始化 → 启动，四步缺一不可。关键不是改配置文件，而是让初始化过程“看见”这个值。
- 停止服务：
systemctl stop mysqld - 备份（可选但强推）：
cp -r /var/lib/mysql /var/lib/mysql.bak - 清空数据目录：
rm -rf /var/lib/mysql/*（注意路径以你的datadir为准） - 初始化命令必须含参数：
mysqld --initialize --user=mysql --datadir=/var/lib/mysql --lower_case_table_names=1 - 确认配置文件
/etc/my.cnf中[mysqld]段也写了lower_case_table_names=1（必须和初始化参数一致，否则下次启动仍可能报错）
验证是否生效：别只看配置文件
启动后登录 MySQL，执行：
SHOW VARIABLES LIKE 'lower_case_table_names';
返回值必须是 1 才算成功。常见误判点：
- 看到配置文件里写了就以为 OK —— 实际初始化没带参，值仍是
0 - 用
SHOW GLOBAL VARIABLES查，结果一样；但重点是初始化那一刻是否对齐 - 建表时用大写名如
CREATE TABLE UserLog，在lower_case_table_names=1下实际存为userlog，后续SELECT * FROM UserLog仍能查到，但ls /var/lib/mysql/yourdb/看到的是小写文件名
生产环境绕不开的坑：已有数据怎么办
如果数据库已上线、有业务数据，重初始化 = 全量重建，代价极高。此时没有“平滑切换”方案：
- 不能导出 SQL 再导入：dump 文件里含大写表名，
lower_case_table_names=1下执行会报table doesn't exist - 不能 rename 表来统一小写：比如
RENAME TABLE OrderDetail TO orderdetail，但若库中已有orderdetail，会冲突 - 唯一较稳的过渡方式：先在开发/测试环境按新规则部署，应用层所有 SQL 和 ORM 显式使用小写表名，再灰度迁移
最常被忽略的一点：lower_case_table_names=1 不仅影响表名，还影响数据库名、视图名、存储过程名——它们全都会被强制转小写，引用时大小写任意，但物理存储和字典记录全是小写。
