必须执行mysql_upgrade，因其负责系统表结构升级和认证插件兼容性处理，跳过将导致连接失败或查询报错；它须在目标版本容器中以mysql用户身份挂载原数据卷后手动执行，不可在旧环境或宿主机运行。
mysql_upgrade 不是必须执行的命令，但跳过它大概率导致后续连接失败或查询报错。MySQL 容器升级的核心不是换镜像，而是处理系统表结构变更和认证插件兼容性。
为什么不能直接 docker pull + docker run 就完事？
MySQL 8.0+ 的 mysql 系统库字段、索引、默认插件都变了。直接复用旧数据目录启动新镜像，容器会启动成功，但首次连接时可能卡住，或者执行 SELECT USER() 报错 Table 'mysql.user' doesn't exist。这不是数据丢了，是新版本 MySQL 拒绝加载未升级的系统表。
- 8.0 → 8.4 升级必须运行
mysql_upgrade（或等容器首次启动自动触发） - 5.7 → 8.0 升级后不运行
mysql_upgrade，SHOW DATABASES可能看不到information_schema以外的库 - 官方镜像在启动时会检测
/var/lib/mysql中的mysql库版本号，若不匹配就拒绝启动（除非加--skip-grant-tables）
mysql_upgrade 必须在什么环境下执行？
它必须在目标版本的 MySQL 进程上下文中运行，也就是要用 mysql:8.4.8 镜像启动的容器里执行，不能在旧容器里跑，也不能在宿主机用本地 mysql 客户端连过去执行。
- 推荐方式：启动一个临时容器，挂载原数据卷，但不自动启动 mysqld，只进 shell 手动跑
mysql_upgrade -u root -p'xxx' - 不推荐方式：在正式新容器启动后，再
docker exec进去补跑 —— 此时部分系统表已加载失败，mysql_upgrade可能报错退出 - 注意：临时容器需加
--user mysql（官方镜像默认用户），否则权限错误导致无法写入mysql库
认证插件不兼容导致连不上，怎么快速修复？
最常见现象是 mysql -h 127.0.0.1 -P 3306 -u root -p 输入密码后无响应，日志里出现 Client does not support authentication protocol。这是因为 8.0+ 默认用 caching_sha2_password，而老客户端（如某些 Python MySQLdb、旧版 Navicat）不支持。
- 临时解法：启动新容器时加配置
default_authentication_plugin=mysql_native_password到/etc/mysql/conf.d/my.cnf - 长期解法：升级后立即重置关键账号插件：
ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx'; - 别漏掉
'root'@'localhost'—— Docker 初始化只设了%，但本地 socket 连接走的是localhost，这个账号仍为caching_sha2_password
SQL mode 和字符集变更引发导入失败
用 mysqldump 备份再导入到新版时，常卡在 INSERT INTO mysql.user 或建表语句上，错误类似 Invalid default value for 'password_last_changed' 或 Specified key was too long。
- 根本原因：8.4 默认启用
STRICT_TRANS_TABLES，且utf8mb4_0900_as_cs排序规则对索引长度更敏感 - 测试阶段可临时禁用严格模式：
--sql-mode=""启动容器，或配置文件中设sql_mode = '' - 生产环境不能关 strict mode，应提前用
mysqlcheck --check-upgrade扫描 dump 文件中的不兼容项 -
VARCHAR(255)字段在 utf8mb4 下索引超限，需改VARCHAR(191)或开启innodb_large_prefix
SELECT user, host, plugin FROM mysql.user;，也没验证 root@localhost 是否可用 —— 这会导致运维人员以为升级成功，结果第二天发现没法本地登录排障。 
