MySQL升级是否影响现有应用取决于版本跨度、SQL模式变更、弃用功能使用情况及隐式依赖；小版本通常安全，跨大版本需全面验证sql_mode、移除函数、字符集、认证插件及存储过程等兼容性。
MySQL 升级是否影响现有应用，取决于版本跨度、SQL 模式变更、弃用功能是否被使用，以及应用层对 MySQL 行为的隐式依赖。小版本升级（如 8.0.33 → 8.0.34）通常安全；跨大版本（如 5.7 → 8.0）则大概率触发兼容性问题，必须提前验证。
检查 sql_mode 变更引发的严格语法报错
MySQL 5.7 默认启用 STRICT_TRANS_TABLES，而 8.0 进一步强化了默认 sql_mode（新增 ONLY_FULL_GROUP_BY、NO_ZERO_DATE 等）。应用中若存在未显式指定 GROUP BY 的查询，或插入零日期（'0000-00-00'），升级后会直接报错。
- 升级前执行
SELECT @@sql_mode;记录当前值，对比目标版本的默认值 - 在测试环境临时设置
sql_mode为 8.0 默认值，运行全量 SQL 回放或核心业务链路 - 避免长期依赖宽松模式；应修正 SQL，而非回退
sql_mode
确认应用是否调用已移除的函数或系统表
MySQL 8.0 彻底移除了 mysql.user 表中的 Password 字段（改用 authentication_string），废弃了 OLD_PASSWORD()、ENCODE()、DECODE() 等函数，并删除了 INFORMATION_SCHEMA.PROCESSLIST（改由 performance_schema.threads 替代）。
- 搜索代码和 ORM 配置中是否硬编码访问
mysql.user.Password - 检查慢日志解析脚本、监控采集逻辑是否依赖已删系统表或字段
- 用
mysqldump --skip-triggers --skip-routines导出时，留意警告中是否提示函数不可用
验证字符集与排序规则（collation）行为差异
MySQL 8.0 将默认字符集从 latin1 改为 utf8mb4，默认排序规则从 latin1_swedish_ci 变为 utf8mb4_0900_ai_ci。该排序规则区分空格、对连字符更敏感，且大小写不敏感语义与旧版不同——可能导致 WHERE name = 'ABC ' 匹配失败，或唯一索引冲突。
- 升级前用
SHOW CREATE TABLE检查各表显式声明的COLLATE，不要依赖默认值 - 对含中文、emoji 或带空格/标点的字段，执行
SELECT ... COLLATE utf8mb4_0900_ai_ci测试等值判断是否一致 - 若业务强依赖旧排序行为，可在建表或列级显式指定
COLLATE utf8mb4_unicode_ci（需评估性能损耗）
连接器与认证插件不兼容导致连接拒绝
MySQL 8.0 默认使用 caching_sha2_password 插件，而老版本客户端（如 MySQL Connector/J 5.x、PyMySQL Public Key Retrieval is not allowed 或直接拒绝认证。
- 升级前确认所有客户端驱动版本：Java 用
mysql-connector-java:8.0.28+，Python 用PyMySQL >= 0.9.3或mysqlclient >= 1.4.6 - 临时兼容方案：启动时加参数
--default-authentication-plugin=mysql_native_password，但仅作过渡 - 不要在生产环境长期禁用
caching_sha2_password；应推动客户端升级
最易被忽略的是存储过程、触发器、事件调度器中隐含的版本相关逻辑，比如依赖 information_schema 字段顺序、使用 FOUND_ROWS() 判断影响行数、或误用 JSON_EXTRACT 返回类型。这些不会在 DDL 检查中暴露，必须通过真实业务流量回放才能发现。
