MySQL 8.0 启动报 MY-011087 错误是因为服务配置与数据字典固化值不一致，该参数只读且不可运行时修改，必须在 mysqld --initialize 阶段通过配置文件和命令行参数双重指定 lower_case_table_names 值，并确保数据目录彻底清空后初始化。
MySQL 8.0 启动时直接报 MY-011087 错误
这不是配置没写对，而是 MySQL 8.0 在启动阶段强制校验：服务层配置的 lower_case_table_names 值，必须和数据字典里固化记录的值完全一致。一旦不匹配（比如配置改成了 1，但数据字典里存的是 0），就会立即拒绝启动，并抛出错误：MY-011087 —— “Different lower_case_table_names settings for server ('1') and data dictionary ('0')”。这个校验在初始化后就不可绕过，不是 warning，是 fatal。
SET GLOBAL lower_case_table_names = 1 总是报 ERROR 1238
lower_case_table_names 在 MySQL 8.0 中是只读变量，运行时无法通过 SET GLOBAL 修改。无论你用什么权限执行，都会收到 ERROR 1238：“Variable 'lower_case_table_names' is a read only variable”。它甚至不会进入变量生效流程，命令一提交就被拦截。云数据库（如阿里云 RDS）控制台里该参数直接灰显，也是因为底层根本没开放写入口。
改了 my.cnf 重启失败，是因为已有数据目录不兼容
Linux 上常见操作：往 /etc/my.cnf 的 [mysqld] 段加 lower_case_table_names=1，然后 systemctl restart mysqld —— 结果服务起不来。原因很直接：/var/lib/mysql 目录下已存在大写表名的文件（如 UserOrder.ibd），而 lower_case_table_names=1 要求所有表名最终都以小写形式存储并被识别。MySQL 不会帮你重命名文件，也不会忽略大小写去匹配，它只按字面路径找文件，找不到就报 Table doesn't exist 或直接崩溃。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 即使你手动
RENAME TABLE UserOrder TO userorder，也只解决单表；视图、触发器、外键定义里的引用仍可能残留大写名 -
mysqldump导出再导入不能“自动转小写”：dump 文件里的CREATE TABLE语句仍按原大小写生成，导入到lower_case_table_names=1实例会失败 - 没有批量修正元数据的 SQL 命令，
INFORMATION_SCHEMA里的table_name字段值也不随文件名 rename 自动更新
唯一能改的时机：mysqld --initialize 阶段
真正能设置 lower_case_table_names 的窗口，只有在数据目录为空、尚未初始化数据字典时。此时必须同时满足两个条件：
- 配置文件里写了
lower_case_table_names=1 - 用命令行参数显式传入：
mysqld --initialize --lower-case-table-names=1 --datadir=/var/lib/mysql（仅靠配置文件不够，MySQL 8.0 要求初始化时双重确认）
之后再启动，数据字典才会以 1 为基准构建。任何已有业务数据的实例，都不在这个安全窗口内 —— 这不是配置问题，是架构级硬约束。
最容易被忽略的一点：即使你清空了 /var/lib/mysql，如果残留了 ibdata1 或 ib_logfile*，初始化也可能复用旧字典元数据，导致值仍为 0。必须确保数据目录彻底干净，且初始化命令中明确指定 --lower-case-table-names 参数。
