检查 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 下直接报错；还有
sysschema 是否自动安装（8.0 默认启用，5.7 没这库），会影响部分监控脚本。
