MySQL升级后配置参数失效主因是默认行为覆盖、语法弃用或加载逻辑变化；需通过SELECT @@global.xxx和SHOW VARIABLES验证运行值，对照官方文档排查废弃参数、配置路径变更及动态设置限制。
MySQL 升级后部分配置参数失效，通常不是“丢了”，而是被新版本的默认行为覆盖、语法弃用或配置加载逻辑变化所致。关键要确认参数是否真的未生效，以及为何没生效。
检查参数是否真的未生效
别只看 my.cnf 文件，必须验证运行时值：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 登录 MySQL 执行 SELECT @@global.sort_buffer_size;（替换为你关心的参数名），对比预期值
- 用 SHOW VARIABLES LIKE 'sort_buffer_size'; 查全局值；SHOW SESSION VARIABLES LIKE 'sort_buffer_size'; 查会话级值
- 注意：有些参数是只读的（如 innodb_version），重启前无法动态修改，只能靠配置文件+重启生效
常见失效原因与对应处理
1. 参数被移除或重命名
MySQL 5.7 → 8.0 或 8.0.x 小版本升级中，不少参数被废弃。例如：
– query_cache_type 和 query_cache_size 在 8.0.3 起彻底移除
– explicit_defaults_for_timestamp 在 8.0.2 默认为 ON，旧配置若显式设为 OFF 可能触发警告甚至拒绝启动
✅ 解决：查对应版本的官方文档 “Removed Options and Variables”，删掉或注释掉已废弃参数
2. 配置文件未被正确加载
升级后 MySQL 可能换了默认配置路径，或启用了新的配置合并逻辑（如 8.0 支持 /etc/my.cnf.d/ 下多个 .cnf 文件）：
– 运行 mysqld --verbose --help | grep "Default options" 看实际读取路径
– 检查 mysqld --print-defaults 输出，确认哪些文件被解析、参数是否出现在其中
✅ 解决：把自定义参数统一挪到被识别的主配置文件（如 /etc/my.cnf），避免分散在多个位置导致覆盖
3. 动态参数被忽略或需特殊方式设置
部分参数虽支持 SET GLOBAL，但有前提：
– 必须在配置文件中先声明（如 max_connections），否则 SET 后重启丢失
– 某些参数（如 innodb_buffer_pool_size）在 8.0 支持在线调整，但需满足最小值限制（不能低于 5MB）
✅ 解决：对关键持久化参数，始终写入 my.cnf 并重启 mysqld；动态调整仅用于临时测试
快速定位变更点的方法
升级前后做一次参数快照比对：
- 升级前执行：mysql -N -s -e "SELECT CONCAT('@', VARIABLE_NAME, ' = ', VARIABLE_VALUE) FROM performance_schema.global_variables ORDER BY VARIABLE_NAME;" > before.cnf
- 升级后同样命令生成 after.cnf，用 diff before.cnf after.cnf 直观看到哪些变了、怎么变的
- 重点关注标红（新增）、标绿（消失）、数值突变（如 tmp_table_size 从 16M 变成 1.6M）的项
预防下次升级出问题
升级前务必做三件事：
- 运行 mysql_upgrade（5.7 及以前）或 mysqld --upgrade=FORCE（8.0.16+），它会检查系统表兼容性，也会提示过时参数
- 用 mysqld --validate-config（8.0.14+）校验配置文件语法和参数有效性，提前报错
- 在测试环境完整走一遍升级流程，包括配置迁移、服务启停、SQL 兼容性验证
