排查 MySQL ERROR 1045 Access denied，从完整报错确认用户、来源 Host、密码和账号状态，并用最小权限恢复宝塔或网站数据库连接。
先读完整报错中的用户、来源主机和 using password：MySQL 的 ERROR 1045 (28000): Access denied for user 不是单纯“密码错”。服务端会用“用户名 + 客户端来源主机”匹配账户，再验证密码、锁定状态和认证方式。先在宝塔面板“数据库”核对应用使用的数据库账号，或在云数据库控制台查看账号与允许来源；不要直接重置 root，也不要把账号改成允许任意主机。
查看账号和授权通常不收费；新建托管数据库、数据库代理、专线或升配可能产生费用。修复 1045 一般不会删除表数据，但改错应用密码、Host 范围或认证插件会让网站持续离线，批量修改多个账号还可能失去管理入口。操作前备份应用数据库配置，保留一个已经验证可用的管理员会话；优先修复或新建专用应用账号，不动正在使用的唯一管理员。
1045、1044 和连接不上不是同一个问题
| 报错 | 所在阶段 | 默认方向 |
|---|---|---|
ERROR 1045 ... Access denied ... (using password: YES/NO) | 服务器已响应，但账户、来源、密码、锁定或认证不通过 | 检查连接参数和准确的 'user'@'host' |
ERROR 1044 ... Access denied ... to database | 通常已识别账户，但没有目标数据库权限 | 检查 SHOW GRANTS 与目标库名 |
Can't connect to MySQL server | 尚未完成 TCP 或 Socket 连接 | 检查服务、地址、端口、Socket、安全组和防火墙 |
MySQL server has gone away | 连接建立后又断开 | 检查空闲超时、大包、重启和网络链路 |
using password: NO 表示客户端没有向服务器提交密码，不证明账号没有密码；先确认应用环境变量是否加载、配置文件是否读到。using password: YES 只表示提交了密码，不代表密码正确。不要把密码直接写进 Shell 命令或截图，避免进入历史记录和日志。
先从失败客户端复现并记录连接方式
同一用户名从 localhost、127.0.0.1、容器地址或远程应用主机连接，可能匹配不同账户。先在真正报错的应用主机上记录连接地址、端口和数据库名，再用客户端交互输入密码。把占位项替换为实际值。
mysql -h 数据库主机 -P 数据库端口 -u 应用用户 -p 数据库名
mysql --protocol=socket -u 应用用户 -p 数据库名
mysql --protocol=tcp -h 127.0.0.1 -P 3306 -u 应用用户 -p 数据库名不要三条都机械执行。第一条用于还原应用实际连接；后两条只用于比较本机 Socket 与 TCP 的差异。若 Socket 成功而 TCP 失败，重点检查连接地址对应的 Host 账户、监听和授权；若两者都 1045，继续查账号和密码；若直接超时或拒绝，应转向网络与服务层。
有可用管理员会话时先做只读检查
使用另一个已验证的管理员账号进入 MySQL，不要关闭现有会话。自建 MySQL 可以查询系统账户；托管数据库可能限制读取 mysql.user，此时改用云控制台的账号管理和官方诊断入口。
SELECT VERSION();
SELECT User, Host, plugin, account_locked
FROM mysql.user
WHERE User = 'APP_USER';
SHOW GRANTS FOR 'APP_USER'@'APP_HOST';把 APP_USER 和 APP_HOST 替换为真实账户，不要把引号内占位符直接复制到生产。查询结果可能包含内部主机范围和权限，保存时要脱敏。没有对应的用户行，说明账号名或 Host 建错；存在多条同名账号时，要判断失败连接实际匹配哪一条；account_locked 为 Y 时，应先确认为什么被锁定，而不是绕过审计直接解锁。
用户名和 Host 为什么最容易配错
MySQL 官方将账户写成 'user_name'@'host_name'。'app'@'localhost' 与 'app'@'10.0.0.8' 是两个账户，可以有不同密码和权限。Docker 容器连接宿主 MySQL 时，数据库看到的来源通常不是 localhost；云数据库看到的也可能是应用实例的私网地址或 NAT 后地址。
默认选择是为应用建立来源范围明确的专用账号：同机应用限制为所需本机连接方式；跨主机应用限制为业务私网网段或确定的主机。不要用 'APP_USER'@'%' 作为快速修复。MySQL 8.4 官方文档还说明，Host 中 % 与 _ 的通配用法已经弃用并可能在未来版本移除；新配置应按当前版本支持的精确地址、主机或网段方式设计。
确认密码错时怎样安全恢复
先排除复制时多出的空格、错误的引号、容器没有重新加载环境变量、WordPress wp-config.php 与实际部署目录不一致等问题。应用配置中若使用特殊字符，要按该配置格式正确转义；不要为了省事改成弱密码。
确需重置时，优先修改专用应用账号，并安排短维护窗口。下面只展示 MySQL 账户语法，真实密码不要写入脚本、工单或公开命令记录；托管数据库应从控制台重置。
ALTER USER 'APP_USER'@'APP_HOST' IDENTIFIED BY 'NEW_STRONG_PASSWORD';修改后立即更新唯一受控的应用密钥来源，滚动重启应用并验证连接。若多个服务共用同一账号，先列出依赖再轮换，避免一部分实例仍使用旧密码。MySQL 的操作记录或客户端历史可能保存语句，生产环境应按密码管理和审计规则执行，不能把真实密码直接留在历史文件里。
能登录但访问数据库时报错怎么处理
如果客户端不指定数据库可以登录，指定某个库后出现 1044，说明认证和数据库权限是两个阶段。先以应用账号连接后执行 SELECT USER(), CURRENT_USER(); 与 SHOW GRANTS;：USER() 反映客户端提交的身份，CURRENT_USER() 反映服务器实际用于权限判断的账户。
SELECT USER(), CURRENT_USER();
SHOW GRANTS;
SELECT DATABASE();只授予应用完成任务所需的库和操作。内容站常见应用需要目标库的读取与必要写入，但不应因此获得所有数据库、用户管理或全局管理权限。不要把 GRANT ALL ON *.* 当作通用修复。授权后重新执行 SHOW GRANTS，再用应用账号完成一次低风险读取和写入验收。
认证插件、旧客户端与云数据库分支
升级 MySQL 后，旧驱动可能不支持服务器使用的认证方式；日志常会出现更明确的插件或握手提示。先记录 MySQL 版本、客户端或语言驱动版本和账户的 plugin，优先升级受支持的驱动。不要为了兼容旧应用就把所有账号改回较弱或已淘汰的认证方式。
托管 MySQL 往往把账号、白名单、SSL 和高权限操作放在云控制台管理，不能假定可以直接修改系统表。先检查账号状态、允许访问的网络、SSL 要求和实例连接地址；安全组或白名单错误通常更像超时，但平台代理也可能返回权限类错误。具体动作以当前云厂商控制台和该实例版本文档为准。
WordPress 和宝塔现场怎么缩小范围
WordPress 显示数据库连接错误时，先确认真实站点目录中的 wp-config.php，核对数据库名、用户名、主机和端口是否对应同一实例。不要在网页或工单里贴出完整配置。数据库服务不可达、连接数耗尽和 1045 的修法不同，可结合WordPress 数据库连接错误排查与MySQL Too many connections 排查分流。
宝塔面板中重设数据库账号后，还要让对应站点配置使用新凭据，并确认 PHP-FPM 或容器已经加载新环境。面板显示“数据库存在”不能证明应用使用的是同一账号和主机。若连接建立后过一段时间才断开，应转到MySQL server has gone away 排查，不要继续反复重置密码。
修复后怎样验证和回退
- 从真实应用主机使用专用账号连接，确认不再出现 1045。
- 执行
SELECT USER(), CURRENT_USER()，确认匹配的账户和来源符合预期。 - 用
SHOW GRANTS核对只拥有目标数据库所需权限，并验证越权操作会被拒绝。 - 启动网站或服务，检查首页、后台登录、一次低风险读取和可回滚写入。
- 观察应用与 MySQL 错误日志，确认旧实例没有继续使用旧密码，也没有产生登录风暴。
若新密码或 Host 配置导致更多实例离线，先恢复保存的应用配置或回滚到原账户凭据，并停止继续扩散变更。若原凭据已经泄露，不应重新启用旧密码；应保留可用管理员会话，创建来源受限的新应用账号，迁移并逐步撤销旧账号。任何回退都要再次检查实际匹配的 CURRENT_USER() 和权限范围。
官方资料
以上资料于 2026 年 9 月 6 日核验。MySQL、MariaDB、云数据库和客户端驱动的版本差异会影响认证与管理入口；本文不把 MySQL 8.4 的行为直接套用于所有版本，执行前应先查看 SELECT VERSION() 与平台官方说明。
联系 Telegram 客服 