必须用MySQL Shell 8.0+执行util.checkForServerUpgrade()做兼容性扫描，严格排除系统库导出、清理MyISAM表及废弃配置，再通过四条SQL验证升级后状态。
不能跳过 util.checkForServerUpgrade()，否则 90% 概率启动失败或半夜告警。 这不是可选步骤，是唯一能提前暴露真实兼容性问题的手段——mysqlcheck、mysqld --validate-config 都不识别跨版本语义变更。
必须用 MySQL Shell 8.0+ 连 5.7 实例跑检查
下载对应目标版本的 MySQL Shell（如升到 8.0.42，就用 mysql-shell-8.0.42），别用 5.7 自带的旧 shell。命令要带 socket 路径，避免连错实例：
./mysqlsh -uroot -p -S /tmp/mysql.sock -e "util.checkForServerUpgrade({'configPath': '/etc/my.cnf'})"
报告里 overallStatus 必须是 OK；出现 ERROR 级条目（比如 Usage of utf8mb3 charset、Column name 'rank' is a reserved keyword）必须逐条修复；WARNING 也不能跳过，例如 caching_sha2_password plugin not supported by client，说明 JDBC 驱动太老，得升级 mysql-connector-java ≥ 8.0.13 或提前切认证插件。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
导出只保业务库，且字符集必须显式指定
绝对不要用 mysqldump --all-databases。5.7 的 mysql 库结构和 8.0 完全不兼容：字段名变了（password → authentication_string），引擎强制为 InnoDB，权限模型也重构了。一旦导入旧 mysql 库，轻则连不上，重则 mysqld 启动直接崩溃。
- 只导出业务库：
mysqldump --default-character-set=utf8mb4 -u root -p --databases myapp_db - 加
--single-transaction --routines --triggers --events，避免锁表和漏定时事件 - 如果已误导出含
mysql库的文件，必须手动删掉所有以CREATE DATABASE mysql或USE mysql开头的段落，再删掉所有INSERT INTO mysql.行
替换二进制后启动失败，90% 是配置或数据字典残留
不是数据坏了，而是校验阶段就被拒载。常见卡在 Starting MySQL 或秒退：
- 删掉或注释掉 5.7 中已废弃的配置项：
query_cache_type、innodb_file_format、explicit_defaults_for_timestamp -
sql_mode里若含NO_AUTO_CREATE_USER，启动直接报错退出，必须删掉 - 确认没有 MyISAM 表：
SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE = 'MyISAM'，非空就得先ALTER TABLE ... ENGINE=InnoDB - 显式设置
default_authentication_plugin=mysql_native_password，否则老客户端连不上；若坚持用caching_sha2_password，JDBC 连接串必须加?serverTimezone=UTC&allowPublicKeyRetrieval=true
最易被忽略的是：升级后 mysql 库必须是全新初始化的，不能是从 5.7 恢复来的；collation-server 和 character_set_server 若仍设为 latin1，虽能启动，但新建库表默认变 utf8mb4，混合字符集极易引发乱码或索引失效。
