mysql版本升级中的配置文件与参数兼容性调整

MySQL 5.7 升级到 8.0 后需重点处理 sql_mode 报错、认证插件变更、废弃参数忽略、系统表升级及权限校验：sql_mode 中 NO_AUTO_CREATE_USER 已移除，须用兼容集；默认认证改为 caching_sha2_password，旧客户端需指定 mysql_native_password；query_cache 相关参数被静默忽略；必须执行 mysqld –upgrade=FORCE 更新系统表；root 默认丢失 FILE 权限。

MySQL 5.7 升级到 8.0 后 sql_mode 报错：Unknown system variable ‘sql_mode’

这不是 配置文件 写错了，而是 MySQL 8.0 默认禁用了旧版兼容模式，且 sql_mode 变量本身在某些启动场景下不可直接查询（尤其使用 --skip-grant-tables 或初始化阶段）。更关键的是，8.0 中部分模式如 NO_AUTO_CREATE_USER 已被移除。

• 检查当前生效的 sql_mode：运行 SELECT @@sql_mode;，而非依赖配置文件注释或旧文档
• 配置文件中若保留已废弃项（如 NO_AUTO_CREATE_USER），mysqld 启动会失败，错误日志明确提示 Unknown or incorrect sql_mode
• 推荐最小安全集（兼容多数业务）：STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION,ONLY_FULL_GROUP_BY；如需兼容老应用，可去掉 ONLY_FULL_GROUP_BY，但不要加已删除项
• 注意：8.0 默认启用 ONLY_FULL_GROUP_BY，很多 GROUP BY 查询会报错，需先评估 SQL 再决定是否关闭

升级后 mysql_native_password 认证插件失效，客户端连不上

MySQL 8.0 默认改用 caching_sha2_password 插件，而老版本客户端（如 MySQL 5.7 客户端、部分 Python MySQLdb 驱动、旧版 Navicat）不支持该插件，连接时抛出 Client does not support authentication protocol requested by server。

• 临时方案（开发 / 测试环境）：创建用户时显式指定旧插件：CREATE USER 'u'@'%' IDENTIFIED WITH mysql_native_password BY 'p';
• 生产环境建议升级客户端驱动，例如 Python 改用 pymysql 或 mysql-connector-python >= 8.0.12
• 全局降级不推荐：修改 default_authentication_plugin=mysql_native_password 仅影响新用户，已有用户密码哈希仍为 sha2，需 ALTER USER …… IDENTIFIED WITH mysql_native_password 重置
• 注意：my.cnf 中该参数只在初始化时生效，升级后修改不会改变已有用户的认证方式

my.cnf 中被忽略或行为变更的关键参数

不少参数在 8.0 中被移除、重命名或语义变化，即使保留在配置文件中也不会报错，但实际不生效或触发意外行为。

• query_cache_type 和 query_cache_size：8.0 彻底移除查询缓存，配置项会被静默忽略，删掉更干净
• innodb_file_per_table：5.7 默认 OFF，8.0 默认 ON；若升级前是 OFF，升级后新建表自动启用独立表空间，但旧表仍是共享表空间（ibdata1），需手动 ALTER TABLE …… ENGINE=InnoDB 迁移
• lower_case_table_names：Linux 下从 0 改为 1 会导致启动失败（因元数据大小写冲突），8.0 要求该值必须与初始化时一致，升级前务必确认
• max_allowed_packet 等运行时参数仍有效，但建议在 [mysqld] 段设置，避免客户端段（[client]）误配导致连接失败

升级脚本中容易漏掉的权限与系统表校验步骤

单纯替换二进制、拷贝配置、重启服务，大概率导致后续权限异常或 INFORMATION_SCHEMA 查询异常——因为 8.0 的系统表结构和权限模型有实质变化（如新增 password_history 表、role_edges 视图）。

• 必须执行 mysql_upgrade（8.0.16+ 已弃用，改用 mysqld --upgrade=FORCE），否则 mysql.help_topic 等表不会更新，部分管理命令失败
• 升级后首次启动会自动运行升级逻辑，但需确保 mysqld 以足够权限运行（如能写 mysql 数据库目录），否则静默跳过
• 检查 performance_schema 是否启用：SELECT COUNT(*) FROM performance_schema.setup_instruments; 若为 0，说明未加载监控项，需确认 performance_schema=ON 且未被其他配置覆盖
• 验证 root 用户是否仍拥有全部权限：SHOW GRANTS FOR 'root'@'localhost';，8.0 默认移除了 FILE 权限，如有 LOAD DATA 需求要手动补回

mysqld --defaults-file=/etc/my.cnf --upgrade=FORCE --user=mysql

升级最麻烦的不是参数改写，而是那些没报错却悄悄失效的配置——比如你以为 query_cache_size=0 还在起作用，其实它早就不认识这个指令了。