mysql启动报错“unknown variable”本质是配置文件含新版本不识别的参数，需用mysqld --validate-config校验并清理query_cache_type、sql-mode等非法项，确认实际加载的配置路径，再通过最小化启动逐步定位冲突参数。
看到“Unknown variable”错误就停，别重启
MySQL启动失败时日志里出现Unknown variable 'query_cache_type'或Unknown variable 'sql-mode'这类报错，说明my.cnf里写了新版本根本不认识的配置项。这不是权限或路径问题，是语法级拒绝——mysqld直接退出，连初始化都不做。此时反复systemctl restart mysqld只会重复失败。
用 --validate-config 快速筛出非法参数
MySQL 5.7.16+ 支持配置校验，比肉眼排查快得多：
mysqld --defaults-file=/etc/my.cnf --validate-config
如果输出空行，说明语法合法；一旦报错，会明确指出哪一行、哪个参数不支持。常见触发点包括：
-
query_cache_type、query_cache_size：MySQL 8.0 起彻底移除，删掉整行 -
sql-mode（带连字符）：必须改成sql_mode（下划线），否则解析失败 -
explicit_defaults_for_timestamp：8.0.2+ 默认启用，若旧配置显式设为OFF，可能被拒绝加载 -
default-storage-engine：应改为default_storage_engine，且值需是InnoDB（8.0 不再支持 MyISAM 系统表）
别只盯一个 my.cnf，确认实际加载的是哪个文件
升级后 MySQL 可能换了默认读取路径，或启用了/etc/my.cnf.d/*.cnf多文件合并机制，你改的文件可能根本没被加载：
运行mysqld --verbose --help | grep "Default options"，看输出中列出的路径顺序；再执行mysqld --print-defaults，它会打印最终生效的所有参数——如果某参数没出现在这里，说明它被忽略或写在了未加载的文件里。
最小化启动 + 逐步加参，定位隐藏冲突
当校验通过但服务仍起不来，可能是多个参数组合引发隐性冲突（比如skip_name_resolve和bind-address配错）：
- 先注释掉
my.cnf里所有非必要参数，只留datadir、socket等最基础项 - 用
mysqld --defaults-file=/etc/my.cnf --user=mysql手动启动，观察是否成功 - 逐段取消注释，每次加 2–3 行，直到复现失败，就能锁定问题参数组
这个过程看起来慢，但比对着错误日志猜来猜去快得多。尤其要注意那些看似“只是提示警告”的参数——MySQL 8.0 对配置合规性更严格，某些警告在旧版可忽略，新版直接拒启。
