临安散人打开终端，输入 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:，这时候手动敲密码，别粘贴。如果手动输入能进去，说明密码本身没问题，问题出在复制粘贴的隐藏字符。如果还是进不去，再考虑密码是否真的被改过。