这个现象非常典型。虽然你“确定”密码是对的但在 Docker 部署 MySQL 的场景下这通常是因为data数据目录里残留了旧的初始化数据导致你新设置的密码根本没有生效。 核心原因Docker MySQL 的“初始化陷阱”MySQL Docker 镜像有一个核心机制只有在第一次启动data目录为空时它才会读取MYSQL_ROOT_PASSWORD环境变量来初始化 root 密码。如果data目录里已经有数据了比如你之前启动失败过留下了损坏的初始化文件它会直接加载旧数据里的密码完全忽略你新设置的环境变量。结合你之前遇到过lower_case_table_names报错导致启动失败你的data目录里很可能留下了一份“密码不一致”的脏数据。✅ 最彻底的解决方案彻底重置实例推荐既然你是新部署的实例里面大概率没有重要业务数据直接清空重来是最快、最稳妥的。1. 停止并删除容器sudodockerstop mysql-8.0.32sudodockerrmmysql-8.0.322. 彻底清空数据目录关键步骤# 删除 data 目录下的所有内容确保下次启动是全新的初始化sudorm-rf/data/mysql/8.0.32/data/*# 确认目录已空应该只显示 . 和 ..ls-la/data/mysql/8.0.32/data/3. 使用简单密码重新启动容器为了避免 shell 转义问题这次我们用一个纯字母数字的简单密码先跑通流程sudodockerrun-d\--namemysql-8.0.32\--restartalways\-p13306:3306\-eMYSQL_ROOT_PASSWORDRoot123456\-eTZAsia/Shanghai\-v/data/mysql/8.0.32/data:/var/lib/mysql\-v/data/mysql/8.0.32/conf/my.cnf:/etc/mysql/conf.d/my.cnf\-v/data/mysql/8.0.32/logs:/var/log/mysql\mysql:8.0.324. 等待初始化完成并测试登录# 等待 10 秒让 MySQL 完成初始化sleep10# 查看日志确认看到 Ready for connectionssudodockerlogs mysql-8.0.32|tail-n20# 使用新密码登录sudodockerexec-itmysql-8.0.32 mysql-uroot-pRoot123456如果这一步能成功进入 MySQL 命令行提示符变成mysql说明问题已解决。 接下来开放外部 IP 访问成功登录后在 MySQL 命令行中执行以下 SQL允许外部 IP 连接-- 1. 允许所有外部 IP 访问或者指定你的 IPCREATEUSERroot%IDENTIFIEDWITHmysql_native_passwordBYRoot123456;GRANTALLPRIVILEGESON*.*TOroot%WITHGRANTOPTION;FLUSHPRIVILEGES;-- 2. 退出EXIT;现在你就可以用 Navicat 或 DBeaver 从外部通过13306端口连接了。 备选方案如果清空数据后依然 Access denied如果你清空了data目录重启后依然报Access denied说明有极其罕见的底层问题。此时可以使用--skip-grant-tables模式强制跳过密码验证来重置# 1. 停止正常容器sudodockerstop mysql-8.0.32# 2. 以跳过权限模式临时启动sudodockerrun-d\--namemysql-temp\-p13306:3306\-v/data/mysql/8.0.32/data:/var/lib/mysql\-v/data/mysql/8.0.32/conf/my.cnf:/etc/mysql/conf.d/my.cnf\mysql:8.0.32\--skip-grant-tables# 3. 无需密码直接进入sudodockerexec-itmysql-temp mysql-uroot进入 MySQL 后执行FLUSHPRIVILEGES;ALTERUSERrootlocalhostIDENTIFIEDBYRoot123456;EXIT;然后删除临时容器正常启动原容器即可sudodockerstop mysql-tempsudodockerrmmysql-tempsudodockerstart mysql-8.0.32建议先执行“彻底重置”方案99% 的情况下能解决你的问题。