根本原因是MySQL 8.0数据字典初始化后锁定lower_case_table_names值，启动时强制校验配置与字典中存储的值是否一致，不匹配即报[MY-011087]错误并退出。
MySQL 8.0 启动报错 [MY-011087] 的根本原因
因为 MySQL 8.0 的数据字典（Data Dictionary）是原子化、持久化在 InnoDB 表里的，不是像 5.7 那样靠文件系统目录和.frm 文件拼凑。一旦初始化完成，lower_case_table_names 的值就被硬编码进数据字典元数据中，后续任何配置文件修改都会被拒绝——服务启动时会严格比对：你配的值 vs 数据字典里存的值。不一致就直接退出，并抛出 [MY-011087] Different lower_case_table_names settings for server ('X') and data dictionary ('Y')。
lower_case_table_names=2 在 Linux 上根本无效
很多用户想“折中”：保留大写建表习惯，又希望查询时不区分大小写，于是试 lower_case_table_names=2。但注意：lower_case_table_names=2 仅在大小写不敏感的文件系统（如 macOS HFS+、Windows NTFS）上受支持；Linux 的 ext4/xfs 是大小写敏感文件系统，MySQL 8.0 在这种环境下压根不接受 2 作为合法值，初始化就会失败。官方文档明确标注该值在 Linux 下“not supported”。
为什么不能 dump/restore 后再改参数？
即使你用 mysqldump 导出全部库再导入新实例，只要目标实例的 lower_case_table_names 值和原实例不同，就可能出问题：
- 导出的 SQL 中表名保持原始大小写（比如
CREATE TABLE UserProfile） - 若新实例设为
1，MySQL 会强制把UserProfile转成小写userprofile存入数据字典 - 但如果你的业务代码里还混着
SELECT * FROM userprofile或SELECT * FROM UserProfile，虽然都能查到，但表名在INFORMATION_SCHEMA.TABLES里统一显示为小写，权限、备份脚本、ORM 映射等环节容易混乱 - 更关键的是：dump 不会重写数据字典本身，新实例仍需按初始化时的
lower_case_table_names值重建字典结构，无法绕过初始化限制
Docker 环境下最容易忽略的初始化时机
在 Docker 中用 mysql:8.0 镜像时，很多人以为挂载自定义 my.cnf 就能控制初始化行为——其实不行。MySQL 容器首次启动时，如果数据卷为空，会自动执行初始化流程（mysqld --initialize），此时才读取 my.cnf 中的 lower_case_table_names。但如果你先启动过一次没配这个参数，数据卷已生成，之后再加配置并重启，MySQL 会跳过初始化，直接加载已有数据字典，导致配置与字典不匹配。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
正确做法只有两个：
- 清空数据卷，确保容器第一次启动时
my.cnf已就位且含lower_case_table_names=1 - 或用
docker run显式传参：--init-file执行建表脚本前先确认大小写策略，但这只是补救，不能改变字典初始化值
真正不可逆的决策点，永远只在第一次写入数据字典那一刻。
