临安散人打开终端，输入 mysql -u root -p，回车后敲入密码，结果屏幕上弹出一句英文——Access denied for user 'root'@'localhost' (using password: YES)。这是几乎所有MySQL使用者都会撞上的一堵墙，尤其是刚装完MySQL、换了新环境、或者在某次改密码之后。我见过太多初级开发者在这一步卡住，有的直接怀疑密码记错了，有的干脆卸载重装，还有人以为数据库损坏了。
先说结论：这个报错大概率不是数据问题，也不是MySQL挂了，而是连接请求在登录授权阶段被拒绝了。换句话说，MySQL收到了你的连接请求、检查了你提交的用户名和密码、然后决定不放你进去。问题可能出在密码、用户名、host匹配、认证插件，甚至客户端连接方式上。这篇文章会把这条报错拆开讲清楚，从最常见的密码错误一路讲到终极兜底方案，结合我在Linux和Windows环境下的实操经验，给你一套能直接照做的排查路径。
1. 报错的完整长相：拆开看它到底在说什么
很多人在网上搜这个报错，复制粘贴了一大段解决方案，但没搞明白报错本身的结构，于是遇到变种就傻眼了。其实MySQL的错误提示很直白，关键是很多人没耐心逐段看。
1.1 ERROR 1045 (28000) 是错误码，不是乱码
完整的报错通常长这样：
text复制ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
ERROR 1045 (28000) 是MySQL返回的错误编号和SQLSTATE值。1045在MySQL错误码里对应的就是访问被拒绝，28000是SQL标准里的invalid authorization specification，翻译过来就是“客户端授权信息无效”。这一串看着唬人，实际上就一句话：认证没通过。
如果你哪天看到别的错误码，比如ERROR 2003、ERROR 1130，那问题性质就不一样了。2003是压根连不上MySQL服务（端口不通或服务没启动），1130是主机被禁止连接，而1045是权限认证问题。先把错误码区分清楚，后续排查方向才对。
1.2 'root'@'localhost' 是MySQL眼里的你，不是操作系统的你
这一段是整个报错信息量最大的地方。'root'@'localhost'里的root是MySQL账号名，localhost表示MySQL服务端认为这个连接来自本机。很多人会把这里的localhost理解成“我自己的电脑”，然后觉得奇怪：“我明明就是在自己电脑上连的啊，为什么拒绝？”
要理解这里，你得换一个视角：MySQL服务端在收到连接请求后，会根据客户端的来源地址去匹配mysql.user表里的账号记录。它会判断“你声称你是谁”和“你来自哪里”，然后决定用哪一条账号记录来验证密码。所以'root'@'localhost'完整的意思是：这次连接尝试使用root账号，并且MySQL将客户端识别为localhost来源。
有个反直觉的点：即使你确实是从本机连的，如果客户端走了TCP/IP协议连到127.0.0.1，MySQL也可能把它识别为localhost或127.0.0.1，取决于服务端的skip_name_resolve设置。后面第三章我会专门讲这个坑。
1.3 using password: YES 不等于密码错误
我第一次看到(using password: YES)时，第一反应是“密码用了加密方式”，后来才发现这个理解完全错了。这段信息只是在告诉客户端：本次连接请求提交了密码。如果这里显示NO，说明客户端发起连接时没带密码，服务端发现这个账号需要密码验证，直接拒绝。所以YES只表示你提交了密码，至于密码对不对，MySQL不会在报错里告诉你。
顺带提一个安全常识：MySQL不会明确告诉你“用户不存在”还是“密码错误”，而是统一返回Access denied。这是为了防止攻击者通过报错信息枚举合法用户名。所以后面做排查时，不要因为报错一模一样就排除“用户不存在”这种可能，得自己想办法确认。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 按出现频率逐个排除：密码、账号、来源地址三大主因
在所有Access denied案例里，密码错误占比最高，其次是host不匹配，最容易被忽略的是账号压根不存在。排除顺序建议按这个思路走：先确认密码，再确认账号，最后检查host匹配。
2.1 第一件事，确认密码是不是真的错了
听起来像废话，但绝大多数人就是倒在这一步。我的建议是不要凭记忆乱试，先想清楚这三个问题：
- 这个MySQL是什么时候装的？当时设置的密码是什么？
- 有没有人改过密码？比如同事、运维、或者安装脚本自动设置过。
- 密码是亲手敲进去的还是复制粘贴的？
刚装完MySQL的新环境有个特殊情况：很多安装方式会在初始化阶段生成一个临时密码，写在日志文件里。比如CentOS上用yum装完MySQL 8.0后，grep 'temporary password' /var/log/mysqld.log能查到初始密码。如果你用的是那种装完自动生成密码的包，却拿自己脑补的密码去登录，必然被拒。
复制粘贴这个细节也很阴间。密码如果来自聊天记录、邮件或密码管理器，粘贴时可能带了首尾空格或换行符，肉眼根本看不见。你看着是123456，MySQL收到的是 123456\n，自然验证不过去。
我建议的验证方法是：先在命令里手动输入一次密码，确认不是复制粘贴的问题：
bash复制mysql -u root -p
回车后MySQL会提示Enter password:，这时候手动敲密码，别粘贴。如果手动输入能进去，说明密码本身没问题，问题出在复制粘贴的隐藏字符。如果还是进不去，再考虑密码是否真的被改过。
2.2 账号可能真的不存在：去mysql.user表里查一查
密码试了几次都不对，很多人会陷入死循环：登录需要密码，忘记密码就进不去，进不去就没法重置密码。如果你手头还有其他能登录MySQL的账号，或者管理员帮你临时开了一个具有查询权限的账号，第一步应该查mysql.user表：
sql复制SELECT user, host, authentication_string, plugin FROM mysql.user;
重点看两列：user和host。你应该能看到root对应多行记录，比如root@localhost、root@127.0.0.1、root@'%'。如果一条root记录都没有，说明用户表被动过手脚——可能有初始化脚本把默认账号删了，或者有人执行过DROP USER 'root'@'localhost';。这时候别急着重置密码，先用当前能登录的账号执行：
sql复制CREATE USER 'root'@'localhost' IDENTIFIED BY '你的新密码';
GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION;
FLUSH PRIVILEGES;
创建完再用root登录，验证是不是能进了。需要说明的是，MySQL对不存在的用户和密码错误的用户返回同样的报错，所以如果你没有第二个账号能进去查表，暂时无法区分这两种情况，可以直接跳到第五章的兜底方案。
2.3 报错里的host变了，说明你的来源地址没匹配上
有时候报错不是'root'@'localhost'，而是'root'@'192.168.1.100'或者'root'@'some-hostname'。这种情况在远程连接MySQL时尤其常见。
我遇到过这么个场景：测试服务器上装好了MySQL，默认只有root@localhost这个账号。开发同学用Navicat从自己电脑连过去，填的账号是root，IP是服务器地址，结果报错Access denied for user 'root'@'118.xx.xx.xx'。为什么会这样？因为MySQL在匹配账号时，不仅要用户名对得上，还要来源地址在mysql.user表里有对应的host记录。root@localhost只允许本机连接，不包含远程IP，所以远程连必然被拒。
解决办法取决于你的需求。如果只是想本机能连，那就保持现状；如果需要远程连接，可以创建一个允许指定IP或所有IP访问的root账号。
sql复制CREATE USER 'root'@'%' IDENTIFIED BY '你的密码';
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;
注意，'%'在MySQL的host列里代表“所有地址”，但它不包含localhost，因为MySQL对host的匹配有优先级，后面会细讲。如果本机也需要用root登录，你得保证root@localhost记录存在，否则本机走socket连接反而匹配不到root@'%'。
3. 密码明明没错却仍被拒绝：三个容易被忽略的隐蔽元凶
有些场景最让人抓狂：密码绝对正确，账号也确实存在，但就是登录失败。这种时候问题通常不在密码本身，而在认证链路中的某些细节上。我挑了三个最容易踩中的隐藏在下面。
3.1 你以为连的是这个MySQL，实际走的通道不同：socket与TCP的差异
MySQL客户端连接本机有两种方式：Unix socket和TCP/IP。默认情况下，命令行执行mysql -u root -p时，如果没写-h参数，客户端会优先走socket文件（通常是/var/run/mysqld/mysqld.sock或/tmp/mysql.sock）。而如果显式写了-h 127.0.0.1或-h localhost，有的客户端会走TCP/IP。
这两种通道在权限校验时可能产生不同的匹配结果。举个例子，我遇到过一次：mysql.user表里存在root@localhost，服务端开启了skip_name_resolve，我执行mysql -u root -p -h 127.0.0.1，结果报Access denied，但去掉-h参数直接连却能进去。
原因在于skip_name_resolve开启后，MySQL不会再对客户端IP做反向DNS解析，于是TCP连接来源127.0.0.1不会被识别成主机名localhost，而mysql.user表里又没有root@127.0.0.1这条记录，所以匹配失败。socket连接则不同，它天然被识别为localhost，因此能匹配上。
验证方法很简单：
bash复制mysql -u root -p
能进，说明socket通道正常。再试：
bash复制mysql -u root -p -h 127.0.0.1
如果这个失败，大概率就是host匹配问题。解决办法是补一条root@127.0.0.1的账号记录，或者把服务端的skip_name_resolve关掉。这个坑在Docker容器场景里特别常见：容器内的MySQL默认只授权了root@localhost，你从宿主机用-h 127.0.0.1去连，端口映射做了，但权限匹配不上。
3.2 认证插件不匹配：MySQL 8.0的caching_sha2_password与老客户端
MySQL 8.0把默认认证插件从mysql_native_password换成了caching_sha2_password。这个改动的安全性更好，但直接后果是：一些老版本客户端和驱动不认识新插件，连接阶段就失败。你输入密码后，客户端用旧的握手协议去验证，服务端返回的却是新插件的认证挑战，两边对不上，最终表现为Access denied。
这类问题有很明显的特征：同一个数据库，命令行新版本客户端能连上，但老版本的Navicat、PHP老版本驱动、Python的旧pymysql连不上。网上很多教程遇到这个问题直接让你改密码，其实应该先查一下账号用的什么插件：
sql复制SELECT user, host, plugin FROM mysql.user WHERE user = 'root';
如果plugin列为caching_sha2_password，而你的客户端确实太老，可以改成兼容模式：
sql复制ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的密码';
改完再试连接基本就能过。不过我的建议是：如果客户端还能升级，优先升级客户端，而不是把服务端降级到mysql_native_password。毕竟8.0换默认插件的目的是强化安全，老插件在密码传输和存储上已经显得落后了。
3.3 Debian/Ubuntu系默认的auth_socket插件：root密码是摆设
这个坑主要集中在Ubuntu和Debian上。用apt install mysql-server装完MySQL后，你执行mysql -u root -p输什么密码都报错，但如果执行sudo mysql却能直接进去。很多人以为是密码问题，折腾半天发现密码根本不存在——因为默认情况下，root账号被配置为auth_socket插件认证。
auth_socket插件的逻辑很简单：不校验密码，只校验当前操作系统用户是不是root（或者与MySQL账号同名的系统用户）。你通过sudo mysql进入时，操作系统用户是root，插件认证通过，所以不需要密码。你想用密码登录，得先把root账号的插件改掉。
用sudo进入MySQL：
bash复制sudo mysql
然后执行：
sql复制ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你想要的密码';
FLUSH PRIVILEGES;
之后再mysql -u root -p就能用密码登录了。这里有个细节：8.0里你也可以用IDENTIFIED WITH caching_sha2_password BY '密码'，这样更贴近默认安全策略。如果只是为了本地开发，用mysql_native_password也问题不大，但建议新项目尽量用默认插件。
顺带说一句，如果你只是希望日常用sudo mysql管理，又想让应用通过TCP用root密码连接，其实可以同时保留两个root账号：一个root@localhost用auth_socket，另一个root@'%'或root@127.0.0.1用密码认证。这样两条通道互不干扰。
4. MySQL 8.0之后的密码重置路径与error 1396
很多人在排到这一步时已经确定密码是忘掉的，于是直接搜“MySQL重置root密码”，照着网上的老办法执行，结果又踩进另一坑：要么命令不生效，要么报错ERROR 1396。这一章讲讲在MySQL 8.0里重置密码的规范动作和容易翻车的细节。
4.1 先搞清楚当前用户用的什么认证方式
在动手重置之前，你得先了解账号当前状态。执行：
bash复制mysql -u root -p
能进就最好，直接查看：
sql复制SELECT user, host, plugin FROM mysql.user WHERE user = 'root';
如果完全进不去，但系统支持sudo mysql（Deiban/Ubuntu默认auth_socket的场景），也可以用sudo进入再查。如果连sudo都进不去，说明这台机器上没有任何入口能进入MySQL，那就直接看第五章，用skip-grant-tables兜底。
这里有一个很重要的分水岭：MySQL 5.7及更早版本里，mysql.user表存密码的字段叫authentication_string，但很多人搜到的教程是UPDATE mysql.user SET Password=PASSWORD('xxx')——那个Password字段在5.7里已经废弃了，8.0里整个PASSWORD()函数都被移除了。如果你拿5.5时代的教程去操作8.0，命令直接报语法错误。
4.2 用ALTER USER重置密码的标准动作
MySQL 8.0里重置密码的正确打开方式是ALTER USER：
sql复制ALTER USER 'root'@'localhost' IDENTIFIED BY '新密码';
执行完后不需要额外FLUSH PRIVILEGES，因为ALTER USER语句本身会更新权限系统。如果你希望兼容老客户端，可以显式指定插件：
sql复制ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '新密码';
注意，如果你当前是通过auth_socket插件登录的root账号，执行ALTER USER ... IDENTIFIED BY会把插件改成默认的caching_sha2_password，同时设置密码。但有些场景下你不希望动插件，只是单纯想重置密码，那插件的选择就得斟酌：保留auth_socket的话密码不会生效，必须改成密码认证插件之一。
MySQL 5.7上的操作类似，只是重置后可能需要手动刷一次权限：
sql复制UPDATE mysql.user SET authentication_string = PASSWORD('新密码') WHERE User = 'root' AND Host = 'localhost';
FLUSH PRIVILEGES;
注意5.7的PASSWORD()函数还能用，8.0里已经移除了，所以上述UPDATE语句在8.0里会报错。这也是为什么我建议能进MySQL的情况下，优先用ALTER USER而不是直接改系统表。
4.3 error 1396出现时的处理思路
重置密码时如果提示：
text复制ERROR 1396 (HY000): Operation ALTER USER failed for 'root'@'localhost'
先别慌，这条报错的意思是：ALTER USER找不到'root'@'localhost'对应的记录。最常见的原因是这张表里压根没有root@localhost，只有root@'%'这类其他host组合。比如我之前在一台云服务器上就见过，初始化脚本把root账号建成了root@'%'，本机socket连接时走的却是localhost来源，所以命令始终报1396。
排查方式还是先查：
sql复制SELECT user, host FROM mysql.user WHERE user = 'root';
如果确实没有root@localhost，说明报错不是密码问题，而是这条记录缺失。创建对应记录即可：
sql复制CREATE USER 'root'@'localhost' IDENTIFIED BY '新密码';
GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION;
FLUSH PRIVILEGES;
如果存在多个host组合，比如说同时有root@localhost和root@'%'，但ALTER USER仍然报1396，还有可能是特殊字符或权限表异常。确保当前登录账号具有CREATE USER权限，并且mysql.user表没有损坏。这种情况不多见，真遇到时可以用DROP USER再CREATE USER的方式重建，但注意DROP USER会连带撤销该账号的所有授权，操作前想清楚。
5. 终极兜底：skip-grant-tables模式下现场重置root账号
前几章讲的方法都有一个前提：你能找到一种方式进入MySQL，比如sudo mysql、第二个管理员账号，或者密码只是被复制时带了空格。但现实中有一种最绝的情况：密码彻底忘了，系统里没有其他账号，sudo也不能用（比如某些MySQL不是apt装的，root账号走的是mysql_native_password，可你忘了密码）。这时候唯一的出路就是让MySQL跳过权限表启动，进去重置root密码。
5.1 什么时候才需要动用这招
skip-grant-tables是MySQL提供的一个启动参数，作用是启动时不加载授权表，客户端登录时跳过权限校验。翻译一下：任何用户都能无密码进入，权限系统完全开放。
正因为如此，这个模式风险极高，我只建议在“彻底无法通过正常途径登录”的紧急情况下使用，并且操作时要做好隔离。如果你在公网服务器上，务必先确保防火墙或安全组不开放3306端口，或者启动时再加一个--skip-networking参数，让MySQL只接受本地socket连接，防止外面的人趁虚而入。
5.2 Linux下完整操作流程
以systemd管理的CentOS/RHEL系列为例，完整流程如下。
第一步，停止MySQL服务：
bash复制systemctl stop mysqld
如果服务名不叫mysqld，可能是mysql或者mariadb，用systemctl list-units | grep -i mysql查一下实际服务名。
第二步，以跳过权限校验的方式启动MySQL，同时禁止网络连接：
bash复制mysqld_safe --skip-grant-tables --skip-networking &
如果你的MySQL安装目录不是标准路径，可能需要用绝对路径，比如：
bash复制/usr/sbin/mysqld_safe --skip-grant-tables --skip-networking &
这一步完成后，MySQL会在后台启动，但不会加载授权表。注意观察终端里有没有报错，如果提示Can't connect to local MySQL server through socket，多半是上一步服务没停干净，或者socket文件路径有问题。
第三步，另开一个终端，无密码登录：
bash复制mysql -u root
因为权限校验已经被跳过，直接回车就能进。进去后先刷新权限表，让后面的ALTER USER能正常执行：
sql复制FLUSH PRIVILEGES;
第四步，修改root账号密码。MySQL 8.0执行：
sql复制ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的新密码';
如果提示root@localhost不存在，先查mysql.user确认host组合，再按需创建或修改。MySQL 5.7执行：
sql复制UPDATE mysql.user SET authentication_string = PASSWORD('你的新密码') WHERE User = 'root' AND Host = 'localhost';
FLUSH PRIVILEGES;
第五步，退出并重启MySQL为正常模式：
bash复制mysql> exit;
# 杀掉当前mysqld进程
kill $(cat /var/run/mysqld/mysqld.pid)
# 或者 pkill mysqld
pkill mysqld
# 正常启动
systemctl start mysqld
然后验证：
bash复制mysql -u root -p
输入新密码，能进就说明重置成功。
整个过程有一个容易翻车的点：在skip-grant-tables模式下，有些MySQL版本直接执行ALTER USER会报错，提示权限表没有初始化。这时候先执行FLUSH PRIVILEGES;再执行ALTER USER通常能解决。原因在于skip-grant-tables模式下服务端没有加载权限相关的内存结构，FLUSH PRIVILEGES迫使它重新加载授权表，之后的ALTER USER才能真正生效。
5.3 Windows下的处理差异
Windows环境思路一致，步骤略有不同。先以管理员身份打开命令行，停止MySQL服务：
bat复制net stop mysql
如果服务名不对，打开“服务”管理器找MySQL相关服务名。然后以前台方式启动：
bat复制mysqld --skip-grant-tables --skip-networking --console
注意窗口不要关，它会占据当前终端。另开一个命令行窗口：
bat复制mysql -u root
进去后同样先FLUSH PRIVILEGES;，再按第4章的方法重置密码。重置完成后，回到第一个窗口按Ctrl+C结束mysqld进程，最后用服务管理器正常启动MySQL服务。
Windows下这个操作有个小差异：如果不加--console，mysqld在后台运行，不容易看到日志，排查问题比较费劲。另外Windows下如果3306端口被占用，mysqld可能启动失败，先确认端口空闲或修改配置里的端口。
6. 平时怎么少撞这堵墙：权限设计的一些个人习惯
每次遇到Access denied，真正解决只是第一步，事后反思才是关键。结合我这些年维护MySQL的经验，整理几个能显著降低撞墙概率的习惯。
6.1 理解MySQL的账号匹配规则：两条根本原则
MySQL在决定是否允许一个连接时，按两条原则走。
第一，根据客户端来源和用户名找到候选账号行。这一过程发生在mysql.user表里。用户名为空（空字符串）的行代表匿名用户，是最后才匹配的兜底选项。
第二，如果有多个host候选行，MySQL会选择最具体的一个。localhost比%更具体，192.168.1.100比192.168.%更具体。这意味着如果你同时有root@localhost和root@'%'，从本机连接时MySQL会优先匹配root@localhost。很多人在本机设置密码只改了root@'%'，忽略了root@localhost，结果本机连接还是用旧密码，自然报Access denied。
理解这一点后，排查维度就清晰了：每次修改账号密码，先确认你要操作的是哪个host组合，最好连root@localhost、root@127.0.0.1、root@'%'都检查一遍。大多数默认安装里，root对应的host变体就那么几个，别只盯着一个改。
6.2 root账号不要裸奔在生产环境
如果你的MySQL服务需要被远程访问，强烈不建议直接开放root的远程登录权限。更稳妥的做法是创建一个业务专用账号，只授予需要的权限：
sql复制CREATE USER 'app_user'@'192.168.1.%' IDENTIFIED BY '强密码';
GRANT SELECT, INSERT, UPDATE, DELETE ON mydb.* TO 'app_user'@'192.168.1.%';
FLUSH PRIVILEGES;
这样即使某个应用被拖库，攻击者拿到的也只是一个受限账号，而不是控制整个MySQL实例的root。root账号平时只用于管理，而且尽量只保留localhost访问方式。这个习惯在Docker等容器化环境里尤其重要，容器端口一旦暴露到公网，root远程登录就是最大隐患。
6.3 我对这类问题的快速自检清单
最后分享一个我自己用过的排查链路，每次遇到Access denied就按这个顺序过一遍，绝大多数问题都能在十分钟内定位：
- 报错中的user和host是什么？我连接时指定的账号和地址是什么？两者是否对应？
- 我有没有办法进入MySQL？如果能，进入后查
mysql.user表，确认目标账号的host、plugin、authentication_string字段。 - 如果走TCP连接，服务端是否开启了
skip_name_resolve？目标账号的host是否匹配客户端的IP？ - 当前MySQL版本是什么？默认认证插件是什么？客户端是否支持？
- 密码里有没有特殊字符？有没有被shell、终端或配置文件转义/修改？
密码里面的特殊字符这个问题我要单独提醒一下。命令行直接执行mysql -u root -p'P@ssw0rd'时，!、$、&等字符会被bash解析，导致MySQL收到的密码并不是你看到的那个。更安全的做法是只写-p然后回车，让MySQL交互式提示输入密码，或者把密码写进~/.my.cnf并设置好文件权限。不过~/.my.cnf里是明文密码，建议只在开发机上用，生产环境最好搭配密钥管理或环境变量方案。
说到底，Access denied这个报错本身并不可怕，它只是MySQL在权限系统里给出的一个“拒绝”信号。只要搞懂用户名、来源地址、认证插件和客户端连接方式这四个维度之间的匹配关系，大多数情况都能自己解决。尤其是别一上来就卸载重装——MySQL的数据目录里存着库表和数据，重装未必能解决问题，还可能把原有数据搞得更糟。先冷静读报错，再按我上面说的链路排查，才是正经做法。