mysql 8.0+ 修改 lower_case_table_names 必须在初始化前完成，因该值固化于数据字典中不可更改，启动时校验服务配置与字典值是否一致，不一致则报错 my-011087 并拒绝启动。
MySQL 8.0+ 修改 lower_case_table_names 必须在初始化前完成
MySQL 8.0 起，lower_case_table_names 是不可动态修改的硬限制参数。一旦数据字典（data dictionary）完成初始化（即首次启动并创建系统表后），再改该值会导致启动失败，报错类似：MY-011087 —— “Different lower_case_table_names settings for server ('1') and data dictionary ('0')”。这不是配置错误，而是 MySQL 8.0 的强制一致性校验：服务层与数据字典必须严格一致。
所以，如果你的实例已运行多时、有业务表存在，直接改配置重启是行不通的。唯一安全路径是：确认当前值，评估是否真需改动；若必须改，只能重建实例。
Linux 上从 0 改为 1 的典型失败场景和真实代价
很多 Linux 用户想让表名不区分大小写（比如适配 Java 驼峰命名生成的 userProfile 表），于是把 lower_case_table_names=0 改成 1。但实际会遇到：
- 原表
UserProfile在磁盘上以大写形式存在，改参后 MySQL 尝试按小写userprofile去找文件，找不到 → 报Table doesn't exist - 即使你手动
RENAME TABLE UserProfile TO userprofile，也仅解决单表；库名、视图、存储过程引用仍可能断裂 -
lower_case_table_names=1要求所有表名最终都存为小写，而 Linux 文件系统本身区分大小写，rename 操作成功不代表元数据完全对齐
更麻烦的是：MySQL 不提供“批量重命名并同步元数据”的原子命令。逐个 rename 后，你还得检查 INFORMATION_SCHEMA、触发器、外键约束中的表名引用是否一致。
能安全操作的唯一窗口：全新实例初始化阶段
如果你正部署新 MySQL 实例（尚未导入任何业务数据），这是唯一可自由设置 lower_case_table_names 的时机：
- 确保配置文件（
/etc/my.cnf或/etc/mysql/my.cnf）的[mysqld]段中明确写入：lower_case_table_names=1 - 删除已有数据目录（如
/var/lib/mysql），清空残留文件（包括ibdata1、ib_logfile*等） - 用
mysqld --initialize初始化，而非直接启动服务 —— 这一步会按配置生成兼容的数据字典 - 启动前确认：
ls -l /var/lib/mysql应为空或只含初始化生成的系统表，且表名全为小写
注意：lower_case_table_names=2 在 Linux 上虽允许“存储保留大小写、比较转小写”，但它不被 MySQL 8.0 官方推荐用于生产，且部分 DDL 操作（如 ALTER TABLE ... RENAME）行为不稳定。
线上环境误改后无法启动？别删数据，先抢救元数据
如果已经改了配置、重启失败，并看到 MY-010119 Aborting 日志，不要直接删 datadir：
- 临时改回原值（比如从
1改回0），尝试启动 —— 若成功，立刻导出所有表结构和数据（用mysqldump --no-create-info+--skip-triggers等组合避坑） - 导出后，停服务，彻底清理 datadir，用正确
lower_case_table_names值重建实例，再导入 - 若连原值都起不来（比如原值是
0，但磁盘上混存了大小写表名），说明文件系统已混乱，此时必须依赖备份恢复，没有绕过手段
最常被忽略的一点：JPA/Hibernate 生成驼峰表名的问题，其实不该靠改 MySQL 参数解决 —— 应在 ORM 层统一配置 PhysicalNamingStrategy 转为下划线命名，让表名天然小写合规。参数不是胶带，贴不住设计缺陷。
