MySQL 8.0+无法启动是因为lower_case_table_names在初始化时已固化至数据字典，重启时严格校验配置值与字典值是否一致，不匹配则报MY-011087错误并中止启动。
MySQL 8.0+ 修改 lower_case_table_names 后无法启动，是因为数据字典已固化初始值，强行修改配置会导致校验失败，服务直接中止。
MySQL 8.0+ 不允许运行时修改 lower_case_table_names
这个参数在初始化数据库时（mysqld --initialize）就被写入数据字典，后续重启时会严格比对配置文件中的值与数据字典记录的值。不一致就报错退出，错误日志里会出现类似：
Different lower_case_table_names settings for server ('1') and data dictionary ('0')
这不是警告，是致命错误，MySQL 拒绝加载数据字典，所以根本起不来。
- 哪怕只是把
my.ini里lower_case_table_names=0改成=1，再重启，也会失败 - Windows 上设
=0还可能触发另一层报错：The server option 'lower_case_table_names' is configured to use case sensitive table names but the data directory is on a case-insensitive filesystem—— 因为 NTFS 默认不区分大小写，MySQL 不允许这种组合 - macOS（APFS/HFS+）同理，也默认不区分大小写，不能设
=0
Linux 下设 lower_case_table_names=1 却启动失败？检查文件系统类型
Linux 虽然默认支持大小写敏感，但如果你用的是 ext4 + casefold 挂载选项，或某些容器/云盘使用了 case-insensitive overlay，MySQL 启动时会自动降级为 =2 并打警告：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
Setting lower_case_table_names=2 because filesystem for /var/lib/mysql/ is case insensitive
此时如果配置文件硬写 =1，就会因实际生效值与配置值冲突而失败。
- 用
findmnt -D /var/lib/mysql查挂载选项，确认有没有casefold或ci - 用
stat -f -c "%T" /var/lib/mysql看文件系统类型，xfs从 v5.12+ 支持 casefold，ext4从 v5.11+ 支持 - 不要依赖“Linux 就一定支持
=0”，得看实际挂载行为
想改 lower_case_table_names 唯一安全路径：重初始化数据目录
不是改配置、不是删文件、不是跳过校验——必须重建整个数据字典。步骤缺一不可：
- 先完整备份
datadir目录（含mysql、sys系统库），否则所有库表元数据丢失 - 停止 MySQL，确认
mysqld进程已退出（ps aux | grep mysqld） - 清空原
datadir（不是删目录，是清空里面所有文件和子目录） - 修改
my.cnf或my.ini，在[mysqld]段明确写入目标值，例如：lower_case_table_names=1 - 执行初始化：
mysqld --initialize-insecure --datadir=/path/to/your/datadir --basedir=/path/to/mysql（注意路径别写错） - 启动服务，再用
mysqldump导入之前备份的逻辑数据（CREATE DATABASE和INSERT）
跨平台迁移时尤其要小心：从 Windows（=1）导出的 dump，在 Linux 上用 =0 初始化后导入，表名大小写不匹配会导致 Table doesn't exist —— 这类问题不会在启动时报错，而是在运行时才暴露。
