select version();是最可靠方式，返回服务器实际运行的完整版本字符串（如8.0.33），不可依赖客户端版本；升级须逐主版本进行，如5.7→8.0允许但需清理弃用特性，8.0→8.4必须逐级升级。
如何用 SQL 快速确认当前 MySQL 版本号
直接执行 SELECT VERSION(); 是最可靠的方式，它返回服务器实际运行的完整版本字符串（如 8.0.33 或 5.7.44）。不要依赖 mysql --version 或包管理器查到的客户端版本，它们和服务器版本可能不一致。
更进一步可查详细信息：SHOW VARIABLES LIKE 'version%';，重点关注 version 和 version_comment 两项。若返回空或报错，说明权限不足或连接异常。
MySQL 主版本间升级是否允许（5.7 → 8.0 / 8.0 → 8.4）
官方只支持相邻主版本间的直接升级，例如：
-
5.7 → 8.0：允许，但需先升级到5.7.39+并完成所有弃用特性清理 -
8.0 → 8.4：不允许直接跳，必须经过8.0 → 8.1 → 8.2 → 8.3 → 8.4（实际仅支持8.0 → 8.1、8.1 → 8.2等逐级路径） -
5.6 → 8.0：明确不支持，必须先升到5.7，再升到8.0
跳过中间主版本会导致 mysqld --upgrade 失败，常见错误是 Table 'mysql.component' doesn't exist 或初始化阶段崩溃。
检查兼容性必须做的三件事
光看版本号不够，必须验证实际环境是否满足目标版本要求：
- 运行
mysql_upgrade前，先用mysqld --no-defaults --validate-config检查配置文件语法是否被新版本废弃（比如query_cache_type在 8.0 中已移除） - 执行
SELECT * FROM information_schema.INNODB_SYS_TABLES WHERE NAME LIKE '%your_db/%';确认表名未使用反引号包裹的保留字（如`order`），否则 8.0+ 会拒绝加载 - 检查存储引擎：如果库中存在
MyISAM表且含全文索引，8.0 升级后将无法启动，必须提前转为InnoDB并重建索引
升级前必须导出并验证的元数据项
自动化脚本常漏掉这些关键字段，导致升级后权限或字符集异常：
- 用户权限：用
SELECT CONCAT('SHOW GRANTS FOR ''', user, '''@''', host, ''';') FROM mysql.user;生成批量语句，再执行导出，避免mysqldump --all-databases遗漏PROXY权限 - 默认字符集：查
SHOW VARIABLES LIKE 'character_set_server';和SHOW VARIABLES LIKE 'collation_server';，8.0 默认改为utf8mb4_0900_as_cs，老应用若没适配排序规则会查不出数据 - SQL mode：
SELECT @@GLOBAL.sql_mode;，8.0 默认启用STRICT_TRANS_TABLES和ONLY_FULL_GROUP_BY，旧 SQL 可能直接报错
真正卡住升级的往往不是大版本号差异，而是某张表的 ROW_FORMAT=COMPRESSED 在 8.0.29+ 被彻底禁用，或者某个触发器里用了已被删除的系统函数 FOUND_ROWS() —— 这些都得在升级前人工扫一遍 information_schema.TRIGGERS 和 information_schema.VIEWS。
