升级后首要确认mysql服务运行及本地连接正常，检查socket路径、skip-networking和bind-address；登录后验证系统表、运行mysql_upgrade（5.7→8.0必需），抽样检查业务表字符集与sql_mode兼容性。
检查 MySQL 服务状态和基础连接
升级后第一件事不是查数据，而是确认服务进程是否真正跑起来了，且能被客户端连上。systemctl status mysql 或 service mysqld status 看状态；用 mysql -u root -p 尝试本地登录。常见失败原因包括：socket 路径变更（新版可能默认用 /var/run/mysqld/mysqld.sock）、skip-networking 仍启用、或 bind-address 锁死了本地访问。
验证关键系统表和权限是否可读
登录后立刻执行 select 1; 和 SELECT USER(), VERSION();，确认会话上下文正常。接着检查 information_schema 和 mysql 库能否查询：SELECT count(*) FROM information_schema.tableS;、SELECT COUNT(*) FROM mysql.user;。如果报错 Table 'mysql.user' doesn't exist 或提示 plugin column doesn't exist，说明 mysql_upgrade 没运行或失败——这是升级后最常被跳过的一步。
运行 mysql_upgrade 并关注输出中的 WARNING
MySQL 5.7 升 8.0 后必须手动运行 mysql_upgrade（8.0.16+ 已弃用，但 5.7→8.0.15 及更早仍需）；而 8.0.x 小版本升级（如 8.0.28→8.0.33）通常不再需要。运行时加 --verbose --force，重点看输出里有没有 WARNING 行，比如：Warning: The user table is not updated 或 Column 'password_last_changed' doesn't exist —— 这类提示往往意味着权限表结构未同步，后续建用户或改密码会出错。
抽样验证业务表的可读性和字符集兼容性
不要全量 SELECT，挑几个典型表：含中文字段的、用 utf8mb4 的、有 json 列的、带全文索引的。执行 SHOW CREATE TABLE `t_order`; 看 DDL 是否完整；再 SELECT id, title FROM t_order LIMIT 1; 确认无乱码、无截断。特别注意：若原库用 utf8（即 utf8mb3），升级后 SHOW VARIABLES LIKE 'character_set%' 中 character_set_server 默认变成 utf8mb4，但旧表的列级字符集不会自动改，插入四字节 emoji 可能失败，得手动 ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4;。
最容易被忽略的是存储过程和触发器里的 SQL_MODE 兼容性——比如旧版允许 GROUP BY 不包含所有非聚合字段，新版 strict mode 下直接报错；还有 sys schema 是否自动安装（8.0 默认启用，5.7 没这库），会影响部分监控脚本。