如何解决MySQL升级后因废弃了系统变量而导致的配置文件启动报错？-mysql教程-PHP中文网

mysql 8.0升级后必须整行删除my.cnf中废弃变量，如query_cache_size、tx_isolation等，注释无效；需用mysqld --validate-config验证，并同步更新jdbc驱动、连接url及sql语法。

如何解决mysql升级后因废弃了系统变量而导致的配置文件启动报错？

MySQL升级后因废弃变量导致启动失败，必须从配置文件中整行删除对应参数，注释掉也不行——8.0解析器会误读注释后的等号或值，直接触发MY-000067错误。

MySQL 8.0 启动时遇到 Unknown system variable 或 MY-000067，基本是以下变量还留在 [mysqld] 段里：

query_cache_size 和 query_cache_type：8.0 完全移除，留着就起不来
tx_isolation：已重命名为 transaction_isolation，旧写法报 ERROR 1193
innodb_file_format、innodb_support_xa、innodb_locks_unsafe_for_binlog：5.7 就废弃，8.0 直接删源码
character_set_name（拼写错误）：正确是 character_set_server，但更常见的是误写成带下划线的变体

特别注意：哪怕你用 # 注释了这些行，只要后面有 =，比如 #query_cache_size = 268435456，8.0 仍可能报错。不是所有注释都安全。

别靠肉眼扫，用命令直击问题源头：

先停服务：systemctl stop mysqld（宝塔用户可在面板点“停止”）
查 MySQL 实际读哪个配置：mysqld --help --verbose 2>/dev/null | grep "Default options"，确认是 /etc/my.cnf 还是 /www/server/mysql/etc/my.cnf
打开那个文件，搜索关键词：query_cache、tx_isolation、innodb_file_format、validate_password，找到就整行删（不是注释）
验证配置合法性：mysqld --defaults-file=/etc/my.cnf --validate-config —— 如果返回空，说明通过；有输出就是还有问题

这个命令比重启试错快得多，且不依赖服务状态。

使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。

下载

配置文件只是第一关。应用层驱动和 SQL 语句也得同步改：

JDBC 驱动必须升级到 mysql-connector-java:8.0.33+ 或至少 5.1.49+；5.1.47 及更早版本会主动发 SET tx_isolation=...，被 8.0 拒绝
连接 URL 中删掉过时参数：&useSSL=true（应为 &useSSL=false 或省略）、&userUnicode=true（正确是 &useUnicode=true）、&serverTimezone 必须显式设置，否则可能间接触发变量解析异常
SQL 里禁用 SET NAMES = 'utf8mb4' 这种带等号的写法——这是语法错误，不是变量赋值；正确是 SET NAMES 'utf8mb4'（无等号）

很多团队卡在这一步：配置文件改对了，但老代码里还藏着 @@tx_isolation 或 JDBC URL 里的过时参数，错误日志却只显示“Unknown system variable”，让人误以为是服务端问题。

最常漏掉的不是变量名，而是配置加载顺序和语法细节：

多个 my.cnf 文件共存时（比如 /etc/my.cnf 和 ~/.my.cnf），后面文件会覆盖前面同名参数；mysqld --verbose --help | grep "Default options" 才是你该编辑的那个
sql_mode 里含 NO_AUTO_CREATE_USER：8.0 已彻底移除，保留会导致启动失败，不是警告
参数值加了多余引号：log_error = "/var/log/mysqld.log" 在某些版本会被当字面量解析失败，应去掉引号
default-time-zone 写成 time_zone：后者是会话级变量，不能放配置文件；且值必须带引号，如 default-time-zone = "+08:00"

真正难排查的，往往不是大变量，而是这些看似无关紧要的拼写、引号、路径和加载优先级。