MySQL 8.4 启动失败主因是配置文件含已移除参数：需删除 sql_mode 中的 NO_AUTO_CREATEUSER、将 MASTER 替换为 SOURCE_、用 binlog_expire_logs_seconds 替代 expire_logs_days，并禁用配置文件设置 lower_case_table_names。
MySQL 8.4 启动失败，八成是配置文件里还留着已被彻底删除的参数，不是语法错、也不是权限问题，就是“旧配置没清理干净”。
sql_mode 包含 NO_AUTO_CREATE_USER 直接拒绝启动
这是最常踩的坑：MySQL 8.0 已标记 NO_AUTO_CREATE_USER 为废弃，到 8.4 中它被完全移除。但很多 my.cnf 还保留着类似这样的写法：sql_mode = STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_AUTO_CREATE_USER。mysqld 启动时会直接报错：Unknown system variable 'sql_mode=NO_AUTO_CREATE_USER'，然后退出。
- 打开配置文件（如
/etc/my.cnf或C:\ProgramData\MySQL\MySQL Server 8.4\my.ini） - 全局搜索
NO_AUTO_CREATE_USER，把它从sql_mode值中整段删掉（注意逗号连贯性，别留下多余逗号） - 其他值如
STRICT_TRANS_TABLES、NO_ENGINE_SUBSTITUTION仍有效，可保留 - 验证配置再重启：
mysqld --defaults-file=/path/to/my.cnf --validate-config（MySQL 8.4 内置命令，不启动实例只校验）
MASTER_* 复制参数全部失效，必须改用 SOURCE_*
所有以 MASTER_ 开头的复制配置项（如 MASTER_HOST、MASTER_USER、MASTER_PASSWORD）在 8.4 中已彻底不可用。继续使用会触发 Unknown system variable 'MASTER_HOST' 类错误，服务无法启动。
- 将配置中所有
MASTER_前缀替换为SOURCE_（例如：SOURCE_HOST、SOURCE_USER） - 注意大小写和拼写——
SOURCE_PORT不是source_port，MySQL 8.4 对变量名严格区分 - 若使用 CHANGE REPLICATION SOURCE TO 语句，也需同步更新语法（
FROM MASTER_HOST→FROM SOURCE_HOST）
expire_logs_days 被移除，必须换成 binlog_expire_logs_seconds
expire_logs_days 在 MySQL 8.x 中已删除，保留它会导致启动失败，错误日志明确提示该变量未知。替代方案是用秒级精度的新参数，且单位必须是秒，不能填天数。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 删掉配置中整行
expire_logs_days = 7 - 替换成
binlog_expire_logs_seconds = 604800（7 天 = 604800 秒） - 该值必须是整数，不能带单位或小数；若设为 0 表示永不过期（谨慎使用）
- 顺手检查是否还有
binlog_format、innodb_log_file_size等已弃用但未报错的警告项——它们虽不阻断启动，但可能影响后续行为
Docker 部署时 lower_case_table_names=1 写进 my.cnf 就卡住
在容器里跑 MySQL 8.4，如果把 lower_case_table_names=1 写进挂载的 my.cnf 或环境变量，mysqld 会反复报 InnoDB: Operating system error number 22 并卡死。这不是配置错，而是 8.4 完全禁止该参数通过配置文件设置。
- 该参数只能在**首次初始化数据目录时**，作为命令行参数传入：
--lower-case-table-names=1 - 必须拼写为带连字符形式（
--lower-case-table-names），不是下划线（lower_case_table_names） - 在
docker-compose.yml中应写在command下：["--lower-case-table-names=1", "--character-set-server=utf8mb4"] - 一旦初始化完成，这个值就永久锁定，任何后续修改都会导致启动失败
真正麻烦的不是哪个参数被删了，而是这些变更互不关联、报错信息又高度相似——比如都显示 “Unknown system variable”，但根源可能是 NO_AUTO_CREATE_USER、MASTER_HOST 或 expire_logs_days 中任意一个。排查时别猜，先用 --validate-config 快速定位具体哪一行出问题，比翻日志快得多。
