MySQL 容器改了密码，为什么还是 Access denied？

修改 MYSQL_ROOT_PASSWORD 或 MYSQL_PASSWORD，重建容器后仍报 ERROR 1045 (28000): Access denied，先看数据目录是否早已初始化。官方镜像不会在每次启动时，用初始化变量重设已有账号密码。

不能为了让登录恢复就删数据卷。已有业务数据时，应该保留目录，检查实际连接目标、账号匹配与仍可用的管理通道。

容器重建不等于数据库重建

假设 Compose 服务名为 db，查看状态、日志和挂载：

docker compose ps
docker compose logs --tail=100 db
docker inspect --format '{{json .Mounts}}' \
  "$(docker compose ps -q db)"

分清命名卷、匿名卷与宿主机目录。日志帮助判断首次初始化还是已有实例启动；容器环境已经显示新值，只能证明新环境传入，不证明数据库账号已改密。

官方镜像在空数据目录初始化账号与数据库，已有目录则保留原状态，见 MySQL 镜像说明。down -v、删除挂载目录或卷清理可能移除业务数据，不是生产改密流程。

宿主机也装了 MySQL 时，客户端用 localhost 可能走本地 socket，而非容器映射端口。若数据库实际发布到宿主机 127.0.0.1:3307，明确用 TCP 测试：

mysql --protocol=TCP -h 127.0.0.1 -P 3307 -u app -p

端口以实际映射为准，-p 后不写密码，由客户端提示输入。应用在另一个同网络容器中时，通常连 db:3306；那个容器的 127.0.0.1 指向它自己。

错误里的用户名和来源地址都要记录。MySQL 账号是用户与 Host 的组合，app@localhost 不必然匹配其他容器；连接目标、来源范围、账号锁定和认证插件都可能影响结果，不能只重复输入密码。

用仍然有效的管理员通道登录，先查条目。下面针对 MySQL 8.0／8.4，不直接套用于其他数据库产品：

SELECT User, Host, plugin, account_locked
FROM mysql.user
WHERE User IN ('root', 'app');

SELECT USER(), CURRENT_USER();

USER() 反映连接身份，CURRENT_USER() 表示实际匹配的认证账号。普通应用无权读系统表时由管理员处理，不为排查给它增加广泛系统权限。

针对确实存在、Host 匹配且插件已确认的账号操作。例如只有已有条目确实为 app@localhost，且使用 caching_sha2_password 时，才按下面语法改密：

ALTER USER 'app'@'localhost'
  IDENTIFIED WITH caching_sha2_password BY '替换为新的长随机密码';

这不会修复其他来源主机的账号匹配。远程应用要使用已经规划的来源范围和最小业务权限，不为了绕过报错把 root 开放给所有地址。MySQL 8.4 仅写 IDENTIFIED BY 会使用默认认证插件，不能假定它总保留旧插件；先核对实际条目与版本再修改。

改密之前保留有效备份和管理通道，安排应用池、定时任务及管理工具更新凭据。数据库和应用两侧都要改，新连接才能一致；真实密码也可能进入 SQL 或管理工具日志，应按已有的凭据与审计流程处理。

Compose 配置的美元符号可能被变量展开，额外引号或合并文件也可能改变值。这不等于某个字符不能作为密码，应检查秘密来源与最终配置方式。读取最终配置时避免把完整凭据输出到聊天、工单或公开日志。

环境变量正确仍不代表已有账号正确，服务端条目与应用端凭据分别核对。管理员全部失效时，使用对应版本正式的密码恢复流程，安排停机与访问隔离；不能用丢弃数据库来代替恢复权限。

修复后，从应用实际网络使用它自己的账号建立新连接，读取必要业务数据，再检查后台任务和原有数据。管理员能登录不能代替应用连接与读写检查。

这类错误多数应在现有实例处理。准备将数据库与应用拆开部署时，再按照Docker 应用的 VPS 与隔离条件安排资源、内网和备份；换一台机器不会自动修复密码、Host 或认证插件。

数据库准备单独迁移时，磁盘按现有数据、导出副本和增长计算，内存按工作集与应用负载观察。需要云资源与网络组合可看 ECS 的实例配置；个人应用共机可比较雨云 RCS 的数据库与应用配置。先用有效管理通道修好账号，再恢复验证新环境；初始化密码变量不会因为换了机器自动修改旧数据里的账号。