mysql版本升级前的环境兼容性检查与评估

升级前须确认MySQL真实版本及运行模式，检查sql_mode、废弃插件、启动参数、SQL兼容性（GROUP BY、保留字、JSON语法）和客户端驱动兼容性。

确认当前 MySQL 版本及已启用的特性

升级前必须明确当前实例的真实版本和运行模式，避免误判为“小版本升级”而忽略不兼容变更。执行 SELECT VERSION(); 仅返回主版本号，需进一步查 SHOW VARIABLES LIKE 'version_compile_machine'; 和 SHOW VARIABLES LIKE 'sql_mode';，尤其注意是否启用了 STRICT_TRANS_TABLES、ONLY_FULL_GROUP_BY 等在 5.7→8.0 中默认开启或行为收紧的模式。

常见错误现象：应用查询突然报错 Expression #1 of ORDER BY clause is not in GROUP BY clause，实则是 8.0 默认启用 ONLY_FULL_GROUP_BY，而旧版未开启或被显式禁用。

• 检查 information_schema.PLUGINS 中是否有已废弃插件（如 FEDERATED 在 8.0.23+ 被移除）
• 运行 SELECT plugin_name, plugin_status FROM information_schema.PLUGINS WHERE plugin_status = 'DISABLED';，确认无依赖禁用插件的业务逻辑
• 导出当前 mysqld 启动参数：mysqld --verbose --help | grep "Default options" -A 1，比对新版文档中已被移除的选项（如 query_cache_type 在 8.0.3 已彻底删除）

扫描 SQL 兼容性问题（特别是 GROUP BY、JSON、关键字）

MySQL 8.0 对 SQL 语法更严格，且引入新保留字，旧 SQL 可能在解析阶段直接失败。不能只靠人工扫代码，需工具辅助。

使用 mysql_upgrade 并不能提前暴露语法问题；它只在升级后校验系统表。真正有效的做法是用目标版本的 mysqld 以 --sql-mode=STRICT_TRANS_TABLES,ONLY_FULL_GROUP_BY 启动临时实例，重放慢日志或典型 SQL。

• 重点检查含隐式 GROUP BY 的查询（如 SELECT a, b FROM t GROUP BY a），8.0 要求所有非聚合字段必须出现在 GROUP BY 中或被函数包裹
• 搜索代码中是否把 rank、json、window 当作列名或别名——它

  

  们在 8.0 是保留关键字，需用反引号包裹
• 验证 JSON 字段操作：旧版用 JSON_EXTRACT(col, '$.field') 没问题，但若用了 col->'$.field' 语法，需确认客户端驱动支持（如 MySQL Connector/J 8.0.12+ 才完全支持）

验证客户端驱动与连接协议兼容性

MySQL 8.0 默认启用 caching_sha2_password 认证插件，老版本驱动（如 MySQL Connector/J Public Key Retrieval is not allowed 或 Authentication plugin 'caching_sha2_password' cannot be loaded。

这不是配置问题，是协议层不兼容。绕过方式（如降级为 mysql_native_password）只是临时缓解，不能代替驱动升级。

• 列出所有接入该库的应用，检查其数据库驱动版本：pip show PyMySQL、mvn dependency:tree | grep mysql
• 测试连接字符串是否显式指定 ?allowPublicKeyRetrieval=true&useSSL=false（仅限测试环境，生产禁用）
• 若使用连接池（如 HikariCP、Druid），确认其底层驱动版本 —— 连接池版本 ≠ 驱动版本

评估性能回归风险（尤其是排序、索引统计、直方图）

8.0 引入了持久化统计信息、直方图、改进的排序算法（sort_buffer_size 行为变化），某些查询可能变慢而非变快。不要假设“新版本一定更快”。

典型场景：分页查询 ORDER BY created_at LIMIT 10000, 20 在 5.7 可能走索引覆盖，但在 8.0 因优化器成本模型调整，可能改走全表扫描 + filesort。

• 在升级前用 EXPLAIN FORMAT=TREE 对核心慢 SQL 重分析（8.0 新增），对比 EXPLAIN FORMAT=TRADITIONAL 输出差异
• 备份并检查当前 innodb_stats_persistent 是否为 ON；若为 OFF，升级后首次重启会触发统计信息重建，可能导致查询计划突变
• 直方图不是自动创建的，但若手动建了（ANALYZE TABLE t UPDATE HISTOGRAM ON col），需确认业务是否依赖其提升范围查询精度

SELECT table_name, column_name, histogram
FROM information_schema.COLUMN_STATISTICS
WHERE schema_name = 'your_db';

真正麻烦的从来不是“能不能升”，而是“升完谁的定时任务开始超时”“哪个报表接口突然 504”。留出足够时间做灰度验证，尤其关注凌晨批处理和低频但关键的管理后台 SQL。