MySQL 升级后 my.cnf
是否必须修改？
不一定需要改，但大概率要调——尤其是跨大版本升级（如 5.7 → 8.0）。MySQL 8.0 废弃/移除了数十个参数，同时新增了关键安全与性能相关配置，旧配置若照搬可能被忽略、报错，甚至导致服务无法启动。
哪些参数在 8.0 中被移除或行为变更？
常见被移除的参数包括：
query_cache_type、
query_cache_size（查询缓存已彻底删除）；
innodb_use_sys_malloc（强制禁用）；
slave_*系列（如
slave_skip_errors）全部改为
replica_*（如
replica_skip_errors）。
以下操作必须做：
搜索并删除所有query_cache_*行，否则 MySQL 启动时会报
unknown variable错误 将
slave_*替换为
replica_*，否则复制线程无法启动
explicit_defaults_for_timestamp在 8.0 默认为
ON，若原配置显式设为
OFF，需评估是否保留（影响 TIMESTAMP 列默认行为）
8.0 新增的关键配置项要不要加？
不是“要不要加”，而是“不加可能出问题”。最常漏配的是：
default_authentication_plugin=cache_sha2_password：8.0 默认认证插件，若客户端（如老版本 PHP PDO、某些监控工具）不支持，连接直接失败
mysql_native_password可临时回退，但建议升级客户端而非降级服务端
require_row_format（配合 binlog）：若开启
binlog_format=ROW且使用 GTID，该参数影响 DDL 复制兼容性
skip_log_bin在升级过程中建议临时启用，避免升级语句写入 binlog 导致从库执行异常
升级后验证配置是否生效的实操步骤
别只看
my.cnf文件，MySQL 实际加载的配置是运行时结果： 登录后执行
SELECT @@version;确认确实是目标版本 执行
SHOW VARIABLES LIKE 'version_compile_machine';和
SHOW VARIABLES LIKE 'have_ssl';排查编译选项差异 用
mysqld --verbose --help | grep "Default options"查看实际读取的配置文件路径（注意
/etc/my.cnf、
/etc/mysql/my.cnf、
~/.my.cnf优先级） 重点检查
SHOW VARIABLES LIKE 'log_error';对应日志里是否有
unknown variable或
deprecated警告
最容易被忽略的是：配置文件中注释掉的旧参数，升级后可能被取消注释或被其他配置覆盖，导致隐性冲突。上线前务必用
mysqld --defaults-file=/etc/my.cnf --validate-config预检。
