mysql升级后my.cnf不一定必须修改，但跨大版本（如5.7→8.0）大概率需调整：须删除query_cache_、替换slave_为replica_*、评估explicit_defaults_for_timestamp；必须添加default_authentication_plugin等关键新参数，并通过--validate-config预检及show variables验证生效。
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 预检。
