直接替换镜像并挂载原有数据卷是最可行的MySQL容器升级路径，但必须执行mysql_upgrade、适配caching_sha2_password认证插件，并确保image版本明确、volumes路径一致、lower_case_table_names等关键配置显式保留，否则90%导致启动崩溃或连接失败。
直接替换镜像 + 挂载原有数据卷是最可行的更新路径，但跳过 mysql_upgrade 或忽略认证插件变更，90% 会导致连接失败或启动崩溃。
用 docker-compose 切换镜像时必须改这三处
只改 image 字段远远不够，容易因配置残留或权限错位启动失败：
-
image值必须明确指定版本号（如mysql:8.4.4），不能用latest—— 否则下次docker-compose pull可能意外升级到不兼容版 - 确保
volumes中挂载的 MySQL 数据目录（通常是/var/lib/mysql）路径与旧容器完全一致，且宿主机目录属主为mysql用户（chown -R mysql:mysql /path/to/mysql/data） - 若旧配置含
lower_case_table_names=1，新版容器启动命令或my.cnf中必须显式保留该参数，否则报错Different lower_case_table_names settings for server ('0') and data dictionary ('1')
不运行 mysql_upgrade 就启新容器？危险操作
MySQL 官方明确要求：跨大版本（如 5.7 → 8.0、8.0 → 8.4）必须执行 mysql_upgrade，否则系统表结构不匹配，SELECT VERSION() 能返回值，但 SHOW DATABASES 或用户权限查询会静默失败。
正确做法是用临时容器挂载原数据卷，手动触发升级：
docker run -it --rm \ -v mysql-data:/var/lib/mysql \ -v $(pwd)/my.cnf:/etc/mysql/my.cnf:ro \ mysql:8.4.4 \ mysql_upgrade -u root -p'yourpass'
注意：mysql_upgrade 在 8.4+ 中已标记为 deprecated，但它仍是必需步骤 —— 实际由容器 entrypoint 自动调用，前提是容器以非守护模式启动并完成初始化流程。
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
连接突然被拒？大概率是 caching_sha2_password 认证插件惹的祸
MySQL 8.0+ 默认使用 caching_sha2_password，而老客户端（尤其 JDBC 8.0 以下、Navicat 旧版、PHP mysqli 扩展）不支持，报错典型如：Client does not support authentication protocol requested by server。
两个务实解法：
- 在
my.cnf的[mysqld]段加一行：default_authentication_plugin=mysql_native_password（仅限测试/内网环境） - 升级后立刻重置 root 密码并强制指定插件：
ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY 'newpass'; FLUSH PRIVILEGES;
别依赖 MYSQL_ROOT_PASSWORD 环境变量重建用户 —— 它只在首次初始化时生效，升级后不会覆盖已有账户的认证方式。
离线环境更新镜像的唯一可靠方式
没有网络的生产服务器上，docker pull 不可用，但 docker load 也不是万能钥匙：
- 先在有网机器执行：
docker save -o mysql-8.4.4.tar mysql:8.4.4 - 传输
.tar文件到目标机，再运行：docker load -i mysql-8.4.4.tar - 关键验证点：
docker images | grep mysql必须显示REPOSITORY为mysql、TAG为8.4.4、IMAGE ID与源机一致 —— 镜像 ID 不同说明加载失败或被本地缓存覆盖
最易被忽略的是：docker-compose.yml 中的 image: 必须写成 mysql:8.4.4，不能写成 localhost:5000/mysql:8.4.4 之类私有仓库格式，除非你真搭了本地 registry 并已推送。
