MySQL 8.4 启动失败主因是配置文件残留已被彻底删除的参数，如NO_AUTO_CREATE_USER、query_cache_type等，必须整行删除而非注释，并用--validate-config校验后重启。
NO_AUTO_CREATE_USER 导致 mysqld 直接退出
这是最常踩的坑：旧 my.cnf 中 sql_mode 值里还带着 NO_AUTO_CREATE_USER，而该参数在 8.4 中已从源码移除，不是 deprecated，是 removed。
- 错误日志明确提示：
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，它能提前暴露这类硬性错误
query_cache_type 等参数被彻底删除，注释也不行
MySQL 8.0 起已移除查询缓存，但很多配置仍残留 query_cache_type=0 或 query_cache_size=0。8.4 解析器遇到这些变量会直接报错 MY-000067，且即使写成注释（如 #query_cache_type=0）也可能因解析器误判而失败。
- 必须从配置中物理删除整行，不能只加
# - 同理清理的还有：
innodb_file_format、innodb_support_xa、tx_isolation、show_old_temporals - 用
mysqld --verbose --help | grep -E "unknown|invalid"可辅助发现残留项
default_authentication_plugin 被移除，改用 authentication_policy
8.4 不再支持 default_authentication_plugin=mysql_native_password，该变量已从代码中删除；同时默认禁用 mysql_native_password 插件，旧客户端连不上不是密码错，是插件根本没加载。
- 若需兼容旧客户端（如老版 Navicat、PHP MySQLi），必须显式启用插件：
mysql_native_password=ON（注意不是mysql_native_password_plugin=ON） - 认证策略应改用新变量：
authentication_policy=SHA256_PASSWORD,CACHING_SHA2_PASSWORD -
default_authentication_plugin写了就报错，删干净再配新参数
innodb_adaptive_hash_index 和 innodb_change_buffering 默认值变了
这类参数没被删，但默认值从 ON/all 变为 OFF/none，导致性能表现突变——尤其对读多写少或写密集型负载，容易误判为“升级后变慢”。
-
innodb_adaptive_hash_index默认OFF：高并发写入场景下更稳定，但全内存只读查询可能略慢；如需开启，必须写进配置并重启 -
innodb_change_buffering默认none：二级索引写入不再缓冲，IOPS 上升、延迟升高；若业务依赖 change buffer 提升吞吐（如日志表高频 INSERT），应回设为all - 这两个参数都不支持运行时动态 SET 生效，必须写入配置文件 + 重启
sql_mode=MYSQL57 看似兜底，实则无法绕过排序规则、系统表结构等底层差异；又比如 innodb_buffer_pool_instances 现在按 CPU 和 buffer pool 大小自动推导，硬写死为 8 可能反而降低并发效率。适配不是删完废弃项就完事，得逐个确认每个保留参数在 8.4 下是否仍是你想要的行为。 
