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 检查中暴露，必须通过真实业务流量回放才能发现。
