MySQL 容器改密码仍 Access denied：初始化变量与数据卷

改初始化变量，不会改已有数据库账号

MySQL 官方镜像已经初始化数据目录后，修改 MYSQL_ROOT_PASSWORD 或 MYSQL_PASSWORD，再重建容器，仍可能报 ERROR 1045 Access denied。这些变量用于初始化，不会在每次启动时重设已有账号。

先保留数据卷和当前配置。容器重建与数据库重建是两件事，不要为了重新触发初始化就删除业务数据。本文针对 MySQL 官方镜像；1Panel 或其他定制镜像还需核对它们自己的初始化方式。

确认实际连接到哪一个实例

在 Compose 项目目录执行下面的只读检查，把 db 换成实际数据库服务名。多副本服务应先明确要检查哪个容器。

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

挂载列表可以确认数据目录来自命名卷还是宿主机路径。日志和容器标识要与应用实际连接目标对应；应用中的 localhost 指向应用容器自己，同网络的 MySQL 通常使用服务名与内部端口。宿主机上另一个 MySQL 可能使用完全不同的账号。

用有效管理通道检查 User 和 Host

如果仍有可用的管理账号，进入数据库交互客户端，密码在提示时输入，避免把密码放到命令参数：

docker compose exec db mysql -u root -p

SELECT VERSION(), @@hostname, @@port;
SELECT USER(), CURRENT_USER();
SELECT User, Host, plugin
FROM mysql.user
WHERE User = 'app';

查看 mysql.user 需要相应权限。MySQL 账号由 User 与 Host 共同标识，app@localhost 和 app@其他主机条件可能是不同账号；CURRENT_USER() 表示本次实际匹配的账号。先检查实际 Host 和认证插件，不默认扩大到所有地址。

修改查到的账号，再同步应用凭据

有权管理账号且确认备份后，使用 ALTER USER 修改已经存在的目标。下面只是假设目标恰好为 app@% 的语法示例；User 和 Host 要按查询结果替换，新密码不要使用示例文字。

ALTER USER 'app'@'%' IDENTIFIED BY '替换为新密码';

保存凭据时按自己的密钥管理方式同步应用，注意客户端历史、终端录屏与日志权限。更改后用应用实际的连接方式测试，再按需重建读取旧环境变量的应用容器。ALTER USER 直接生效，不需要为这个操作另外执行 FLUSH PRIVILEGES。

如果所有管理凭据都失效，先按正在运行的 MySQL 版本和镜像恢复流程处理。本文的有效管理账号步骤不能用于绕过认证，也不通过临时删除数据目录找回密码。

还有 Access denied 时核查配置展开

检查 Compose 使用了哪个 env 文件、应用是否读取 secret 文件，以及密码中的美元符号、引号和连接 URL 转义是否改变了实际值。docker compose config 可能包含展开后的秘密，只在受控终端检查，不贴进公开工单或文章评论。

对照错误发生时间重新读应用日志。账号密码一致后仍失败，就继续检查匹配的 Host、插件、驱动和所需权限；不要反复重建数据库容器，期待初始化变量覆盖原数据。