MySQL 8.0 启动时强制校验数据字典值，不读配置文件；其 lower_case_table_names 值在初始化时固化进 mysql.ibd，启动需确保配置、命令行参数、磁盘文件名及字典记录四者完全一致，否则报 MY-011087 拒绝加载。
MySQL 8.0 启动时直接校验数据字典里的值，不是读配置
MySQL 8.0 把 lower_case_table_names 的值写进了数据字典（mysql.ibd），启动时会强制比对：配置文件里写的值、命令行传的值、磁盘上实际表名格式、数据字典里记录的“规范名”——四者必须完全一致。不一致就拒绝加载，报错类似 MY-011087 或日志里明确提示 Different lower_case_table_names settings for server ('1') and data dictionary ('0')。
这不是配置没生效，而是 MySQL 已经把初始化那一刻的设定当成元数据结构的一部分了。你改 my.cnf、删注释、加空格，都没用。
Linux 上从 0 改成 1 为什么物理文件找不到表？
当 lower_case_table_names=0 时，CREATE TABLE UserProfile 会在磁盘生成 UserProfile.frm（或 UserProfile.ibd）；改成 =1 后，MySQL 默认按小写 userprofile 去找文件，但该文件根本不存在。
-
SHOW TABLES还能看见UserProfile，是因为元数据里还存着这个名字，但访问路径失败 - 手动
RENAME TABLE `UserProfile` TO `userprofile`只解决单表，外键、视图、存储过程里的引用不会自动更新 - Linux 文件系统本身区分大小写，
rename成功 ≠ 元数据对齐，更不等于所有依赖都安全
为什么命令行参数 --lower-case-table-names 才有效，my.cnf 无效？
MySQL 8.0 初始化阶段（mysqld --initialize）只认命令行显式传入的 --lower-case-table-names=0，完全忽略 my.cnf 里的同名配置。这是很多文档漏掉的关键点。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
常见误操作：
- 先写好
my.cnf，再直接systemctl start mysqld→ 实际走的是默认初始化逻辑，lower_case_table_names按系统平台决定（Linux 默认 0） - 初始化完再补
my.cnf配置 → 无意义，数据字典已定型 - 用
--initialize-insecure但没带--lower-case-table-names参数 → 等于没指定，按平台默认值固化
误设后唯一能做的就是重来
只要 mysqld --initialize 执行过一次、服务成功启动过，数据字典就不可逆。没有“热修复”，没有“迁移工具”，没有“一键转换脚本”。
你面对的不是一个配置问题，而是一个元数据一致性约束。真正容易被忽略的是：哪怕只是本地 Docker 试跑过一次 MySQL 8.0 容器（macOS 默认 =2），导出的 SQL 迁到 Linux 生产环境时，也必须清空 datadir、用命令行参数重新初始化，否则必卡在启动阶段。
