MySQL 版本升级后 my.cnf
是否必须修改？
不一定需要改，但大概率要调。MySQL 主版本升级（如 5.7 → 8.0）会废弃、重命名或改变大量配置项的行为，直接复用旧
my.cnf可能导致服务启动失败、参数被忽略，或隐性性能退化。
关键判断依据是：启动时 MySQL 是否报出
unknown variable或
deprecated警告；以及
SHOW VARIABLES返回值是否与预期一致。
哪些配置项在 8.0+ 中最常出问题？
以下参数在 MySQL 8.0 后已被移除、重命名或语义变更，旧配置若保留，轻则无效，重则阻断启动：
query_cache_type和
query_cache_size：8.0 彻底移除，删掉这两行，否则启动报错
innodb_file_per_table：8.0 默认为
ON，无需再显式设置；若旧配置写成
1或
TRUE，虽不报错但冗余
explicit_defaults_for_timestamp：8.0.2+ 默认
ON，且该变量已废弃，继续写会触发 warning
sql_mode中的
NO_AUTO_CREATE_USER：8.0.11+ 移除，若还保留在 sql_mode 字符串里，MySQL 会拒绝启动
default_authentication_plugin：5.7 默认
mysql_native_password，8.0+ 默认
caching_sha2_password；若应用连接器不支持后者，需显式设回前者
如何安全迁移 my.cnf
配置？
别手动逐条对照文档改。推荐三步走：
用新版本 MySQL 的默认配置文件做基准：安装包里的my.cnf（如
/usr/my.cnf）或运行
mysqld --help --verbose | grep "Default options"找到内置默认路径 用
mysqld --defaults-file=/path/to/old.cnf --verbose --help | grep "would have been used"检查旧配置中哪些行实际生效（避免注释干扰） 对比两份配置，只把业务强依赖的、有明确调优目标的参数（如
innodb_buffer_pool_size、
max_connections）迁移到新文件，其余按新版默认值走 启动前务必执行：
mysqld --defaults-file=/new.cnf --validate-config，它会提前暴露语法和弃用问题
升级后还要验证哪些隐藏配置影响？
有些“配置”不在
my.cnf里，但升级后行为突变，容易漏检： 字符集相关：
character_set_server和
collation_server在 8.0 默认为
utf8mb4/
utf8mb4_0900_ai_ci，若旧库用
utf8mb4_unicode_ci，排序结果可能不同 SQL 模式：
ONLY_FULL_GROUP_BY在 8.0 默认启用，未显式关闭可能导致原有 GROUP BY 查询报错 密码策略：
validate_password插件在 8.0 默认启用且强度更高，新建用户可能因密码太简单被拒 系统表权限：8.0 引入了更细粒度的权限（如
BACKUP_ADMIN），但旧账号若只靠
GRANT ALL PRIVILEGES授予，可能缺必要权限，导致备份工具失败
真正麻烦的不是配置改不改，而是那些没写进
my.cnf、却固化在 SQL 逻辑或运维脚本里的隐式假设——比如默认排序规则、GROUP BY 宽松度、甚至客户端连接时没指定
default-auth导致握手失败。
