先说个我自己经历过的糟心事一个跑了大半年的项目某天早上同事告诉我测试库连不上了控制台刷出一行ERROR 1045 (28000): Access denied for user rootlocalhost (using password: YES)。我当时第一反应是“密码被改了吧”折腾了半小时才发现根本不是密码问题而是权限表和账号 host 匹配的坑。那次之后我就明白了MySQL 1045 是日常开发里被问得最多的报错之一解决起来说难不难但排查思路不对白费几个小时也是常事。这篇文章我不打算只给一个“重置密码”的万能方子。我会把 1045 报错从头到尾拆开讲错误信息里每段英文什么意思、哪些原因会导致它、不同场景该怎么一步步验证和处理。文章覆盖命令行连接失败、Navicat 连不上、Workbench 报错、Java/JDBC 连接被拒这些高频情况刚装好 MySQL 的新手能照着操作踩过几次坑的老手也能当排查手册翻。1. 先弄清1045错误的真实含义报错拆解与影响范围1.1 逐段拆解错误信息明白MySQL到底拒了什么很多同志看到一长串英文就发慌其实这个报错拆开看非常直白。拿最常见的完整信息来说ERROR 1045 (28000): Access denied for user rootlocalhost (using password: YES)这里有几个关键部分要分开理解。1045是 MySQL 的错误码含义就是“用户访问被拒绝”。28000是 SQLSTATE 标准状态码在 ODBC/JDBC 这类连接场景里会先看到它。Access denied for user rootlocalhost这一段说的是MySQL 服务端明确知道有个人想以root这个用户名、从localhost这台主机发起连接但服务端拒绝了这次认证。后面括号里的using password: YES也很有讲究。它表示客户端在连接时确实发送了密码。如果这里显示的是NO说明客户端压根没给密码那问题通常不是密码错误而是“你连密码都没传”。看到YES则说明密码传了但服务端校验没通过。这一行信息基本能告诉你MySQL 服务是活的网络是通的卡点就在“身份认证”这一环上。1.2 别把认证失败和连接失败混为一谈排查 1045 之前我建议你先确认一件事你要处理的到底是认证失败还是连接失败。这两个问题完全不同处理方向也完全不同。如果报错是ERROR 2003 (HY000): Cant connect to MySQL server on localhost (10061)说明服务端口没开、防火墙拦截、或者 MySQL 进程根本没起来这是网络和服务层面的问题跟密码一点关系都没有。而1045这个错误码本身说明 TCP 连接已经建立了MySQL 服务端也响应了只是拒绝你的登录请求。打个比方2003 是“你敲了门屋里没人”1045 是“门开了门卫查了你的证件发现你不是本人直接把你拦在门外”。所以看到 1045核心排查范围就锁定在用户名、密码、来源主机、权限表、认证插件这几类因素上不需要去查防火墙和端口。1.3 哪些场景最容易触发1045根据我这些年处理的案例1045 基本集中在这么几个场景里刚装完 MySQL用 root 登录输错密码或者压根不知道初始密码。长时间没连数据库把密码记混了或者密码被其他同事改过。用 Navicat、Workbench 等图形化工具连接配置里主机地址写的是127.0.0.1但 MySQL 用户表里只有localhost记录。项目用的老版本 JDBC 驱动连接 MySQL 8客户端不支持新的密码认证插件。之前用--skip-grant-tables跳过认证改了密码重启后忘了关开关或者改完没正确刷新权限表。搞清楚自己属于哪一类后面找解决方案就快了。2. 汇总6种常见成因同样是root被拒原因可能完全不同2.1 密码错误和密码确实没设置好1045 最常见的诱发因素就是密码不对但“不对”也分很多种情况。有的人是拼写错误有的人是键盘大小写问题还有人是因为 MySQL 5.7 及以上版本安装后会生成一个临时密码安装日志里那一串字符复制的时候多复制了一个空格导致登录一直失败。另外有个冷知识早期 MySQL 安装完成后 root 可能是空密码。如果你装的是旧版本或者用了某些集成环境root 的默认密码是空。这时候在命令行直接mysql -uroot -p后回车、密码位置直接按回车就能进。一旦你输入了某个字符反而会因为密码校验失败报 1045。所以遇到 1045先别急着重置密码试着用空密码登一次成本只有一秒钟。2.2 host字段不匹配localhost不等于127.0.0.1这是很多人容易忽略的点。MySQL 用户表mysql.user里的记录是user host共同组成一个用户rootlocalhost和root127.0.0.1在 MySQL 看来完全是两个账号。如果你用mysql -uroot -h127.0.0.1 -p去登录但服务器上只有rootlocalhost这个账号逻辑上是会匹配失败的。同样从局域网内另一台机器用-h服务器IP连接账号的 host 必须是%或者对应 IP否则就算密码对了也提示 1045。这里的本质不是密码错而是“没有匹配到任何合法账号”。2.3 权限表被改动root账号处于半残状态还有一种比较隐蔽的情况有人手动操作过mysql.user表或者执行过一些不完全的 GRANT/REVOKE 语句导致 root 账号的权限记录、plugin 字段、authentication_string 字段之间对不上。比如plugin字段变成空或者authentication_string里的哈希内容被清掉都会让认证失败。我记得有个朋友做运维实验用UPDATE mysql.user SET authentication_stringPASSWORD(123456) WHERE Userroot;改密码结果在 MySQL 5.7 上执行成功但登录照样报 1045。原因就是他修改的字段和 MySQL 5.7 的认证机制不匹配改了等于没改反而把原本正常的状态搞乱了。这类问题排查起来比较麻烦通常需要跳过认证进入系统检查 user 表。2.4 密码认证插件不兼容老客户端连MySQL 8的典型症状MySQL 8.0 默认的密码认证插件是caching_sha2_password而 MySQL 5.7 及更早版本默认是mysql_native_password。如果你的客户端工具比较老比如早期版本的 Navicat、旧版 JDBC 驱动它不支持caching_sha2_password这种新插件服务端和客户端在认证握手阶段就会失败报出来的错误同样是 1045。这个问题的特征很明显密码确定是对的命令行用新版客户端能连上但老工具连不上。网上大量“Navicat 连接 MySQL 8 报错 1045”的帖子八成都是这个原因。解决思路要么升级客户端要么把用户改成mysql_native_password插件或者新建一个指定旧插件的账号。2.5 安装初始化时留下的临时密码没被正确修改装 MySQL 5.7 以上版本时初始化脚本会自动为 root 生成一个临时密码路径一般在错误日志里比如/var/log/mysqld.log中的[Note] A temporary password is generated for rootlocalhost: xxxxxx。用这个临时密码登录后MySQL 会强制你先设置新密码才能继续操作。很多人报 1045 就是卡在这一步要么没找到临时密码要么复制的临时密码带了特殊符号导致输入错误要么改密码的 SQL 语法不兼容。我不知道你用的是不是这种情况但至少排查时要考虑到“新装环境”这个前提。2.6 skip-grant-tables开关残留导致认证机制异常--skip-grant-tables是忘记密码时的救命稻草但也是安全隐患。如果开启它启动 MySQL任何本地用户都能不输密码直接以 root 身份进入。如果改完密码后你忘了关闭这个开关MySQL 仍然处于“跳过认证”模式此时你会发现无论输什么密码都会出现奇怪的认证异常甚至某些 SQL 操作被限制。还有一种衍生情况你在跳过认证模式下用ALTER USER修改密码但没先执行FLUSH PRIVILEGES导致修改结果没生效恢复正常模式后照样报 1045。这些都是“开关残留”引发的连锁问题后面方案章节我会详细说正确流程。3. 排查第一关确认连接参数与服务状态避免白忙一场3.1 命令行直连用最原始方式确认密码对不对排查 1045 的第一步我强烈建议先抛开 Navicat、Workbench、JDBC 这些中间层直接在本机用命令行连接一次。原因很简单客户端工具可能缓存了配置、可能版本太老、可能装了代理插件这些都会干扰判断。命令行是最简路径能最快区分“密码错”和“其他问题”。Linux 和 macOS 下执行mysql -uroot -pWindows 的 CMD 或 PowerShell 下执行mysql -uroot -p如果你本机没把 mysql 命令加入环境变量需要先切到 MySQL 安装目录的 bin 文件夹下面执行。输入密码时屏幕上不会显示任何字符这不是键盘坏了而是终端故意不回显。很多人在这里反复输错就是因为不习惯这个设定。如果命令行能正常进入那问题就出在你原本使用的客户端或者连接参数上。如果命令行也报 1045那就进入下一步确认主机名和端口。3.2 localhost和127.0.0.1要分开测试命令行连接时你可以分别试一下这两种方式mysql -uroot -p mysql -uroot -h127.0.0.1 -P3306 -p mysql -uroot -hlocalhost -P3306 -p注意区别在于-hlocalhost在大多数系统上会走 Unix socket 文件-h127.0.0.1走 TCP 网络协议。两者的连接路径不同MySQL 匹配用户 host 的逻辑也可能不同。如果你在某个方式下能连上另一个方式下报 1045基本可以断定是 host 匹配问题而不是密码问题。顺便提一句端口如果你在配置文件里修改了 MySQL 端口比如改成 3307连接时没有指定-P3307默认去连 3306 会报连接失败但那个报错会是 2003 而不是 1045。如果看到 1045至少说明端口和网络是通了的。3.3 确认MySQL服务运行状态和基本配置虽然 1045 基本意味着 MySQL 服务在运行但为了稳妥还是建议看一眼服务状态。Linux 下可以用systemctl status mysqld # 或者 service mysql statusWindows 下打开服务管理器找 MySQL 相关服务确认状态是“正在运行”。如果你用的是 Docker 部署的 MySQL那就用docker ps | grep mysql另外在排查前看一眼 MySQL 配置文件my.cnf或my.ini确认没有残留skip-grant-tables。如果发现这个配置还在且处于生效状态先把那一行注释掉重启 MySQL 服务再用正常方式连接。我排过不少案例对方折腾了半天其实罪魁祸首就是配置文件里的这一行开关。4. 核心操作忘记root密码时的标准重置流程4.1 理解skip-grant-tables的救急原理在进入操作之前我先解释一下这套方法的原理。MySQL 启动时默认会加载mysql库下的权限表包括user、db、tables_priv等。每次客户端连入时MySQL 会查这些表来验证身份和权限。--skip-grant-tables选项的作用就是告诉 MySQL 启动时不要加载这些权限表认证阶段直接放行。这样你就能在不提供密码的情况下进入 MySQL然后手动修复权限数据。注意这个操作必须在服务端启动时加参数而不是在客户端连接时加。它是给“进都进不去”的绝境准备的。由于跳过认证的模式安全风险极高修复完密码后必须关闭这个开关再以正常模式启动服务。如果是生产环境还要特别注意操作窗口期的安全防护最好在防火墙策略下操作避免别人趁虚而入。4.2 Windows环境修改配置启动跳过认证Windows 上我推荐用修改配置文件的方式操作比命令行手动启动服务端更直观。第一步停止 MySQL 服务。在管理员权限的 CMD 里执行net stop mysql如果服务名不是mysql到服务管理器里查一下具体的服务名。停止服务是为了避免配置文件和运行中进程的状态不一致。第二步找到 MySQL 的配置文件my.ini一般在安装目录下。在[mysqld]段加入一行skip-grant-tables保存后重新启动 MySQL 服务net start mysql第三步此时 MySQL 处于免认证模式在命令行执行mysql -uroot -p要求输入密码时直接按回车应该能进入 MySQL 环境。进去后第一件事执行FLUSH PRIVILEGES;这一步很重要它让内存中的权限数据重新加载。如果你不执行直接修改密码可能不生效。4.3 Linux环境利用mysqld_safe或配置文件进入Linux 上同样有两种常见方式。第一种和 Windows 类似修改/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf在[mysqld]段加一行skip-grant-tables然后重启systemctl restart mysqld第二种方式是直接命令行启动一个临时实例适用于不想改配置文件的场景systemctl stop mysqld mysqld_safe --skip-grant-tables 注意mysqld_safe启动后服务是以后台方式运行的。连接的时候照旧用mysql -uroot -p # 密码直接回车使用第二种方式时操作完成后要记得停掉 mysqld_safe 后台进程再以正常配置启动 mysqldmysqladmin shutdown systemctl start mysqld这里尤其要强调整个过程要胆大心细。你现在拥有的是免认证的 root 权限任何一步误操作都可能造成权限表进一步损坏。4.4 不同版本的重置密码SQL写法进入 MySQL 环境后根据版本不同重置密码的 SQL 写法有差异。首先需要确认一下当前 MySQL 版本执行SELECT VERSION();如果是 MySQL 5.7.6 及以上版本比如常见的 5.7、8.0推荐用ALTER USER方式ALTER USER rootlocalhost IDENTIFIED BY 你的新密码;如果这个账号的 host 是%那要改成对应 host比如ALTER USER root% IDENTIFIED BY 你的新密码;如果是 MySQL 5.7.5 及更早的版本可以用SET PASSWORDSET PASSWORD FOR rootlocalhost PASSWORD(你的新密码);需要特别提醒MySQL 8.0 已经移除了PASSWORD()函数如果你用旧语法直接报FUNCTION mysql.PASSWORD does not exist。在新版本上老老实实用ALTER USER就行。密码设置上MySQL 有默认的密码策略。如果设置的密码太简单比如123456MySQL 8 会报校验失败提示ERROR 1819 (HY000): Your password does not satisfy the current policy requirements。如果遇到这个要么把密码设置得更复杂比如大小写字母加数字加特殊符号要么临时修改密码策略SET GLOBAL validate_password.policy LOW;低版本 MySQL 5.7 的变量名略有不同可能是validate_password_policy。这个设置会影响数据库安全性测试环境用一下没问题生产环境我建议保持高强度密码。4.5 恢复正常模式并验证修改完密码后必须关闭跳过认证的开关。把配置文件里加的skip-grant-tables删除或注释掉然后重启 MySQLWindows:net stop mysql net start mysqlLinux:systemctl restart mysqld恢复正常模式后再执行一次连接验证mysql -uroot -p输入你刚设置的新密码如果能进入到这里重置操作就完成了。有个小细节如果重启后仍然报 1045先怀疑是不是配置文件没改干净再怀疑是不是账户 host 不对这个顺序能节省不少时间。5. 权限与host匹配问题同样是root为何有时连不上5.1 查看mysql.user表掌握账号全貌有时候密码明明是对的但就是报 1045那就需要深入检查mysql.user表。进入 MySQL 后执行SELECT user, host, plugin, authentication_string FROM mysql.user;执行结果会列出所有账号以及对应的允许来源主机、认证插件。重点看 root 相关的行。正常情况下应该有一行rootlocalhost。如果只有root127.0.0.1那你用 localhost 连接时就会匹配不到。如果没有任何 root 记录那问题更严重——要么是安装时初始化异常要么是有人误删了系统账户需要新建 root 或者至少建一个能用的管理员账号。5.2 host匹配规则localhost、127.0.0.1、%的区别MySQL 验证用户时会按user host的组合来匹配。host 字段的规则有一些细节需要理解localhost只允许从本机通过 socket 或本机回环地址连接。127.0.0.1只允许从本机的 IPv4 回环地址连接注意它和localhost并不完全等价。::1IPv6 回环地址。%通配符表示允许从任何主机连接常用于远程账号。192.168.1.%允许从该网段连接。MySQL 匹配用户时会按主机从精确到模糊排序如果同时存在rootlocalhost和root%从本机连接时会优先匹配rootlocalhost。所以即使root%的密码正确但如果rootlocalhost的密码不对从本机连接时照样会报 1045因为它命中的是 host 更精确的那条记录。这种情况很容易让人误以为“root 密码怎么改都没用”其实是“改错了对象”。排查思路是查看当前连接命令里的-h参数到底匹配到 user 表中的哪一行。5.3 为root或其他账号创建正确的host记录如果需要让 root 能从本机正常连接最简单的办法是确保存在rootlocalhost账号并重置它的密码。如果不存在可以创建CREATE USER rootlocalhost IDENTIFIED BY 你的新密码; GRANT ALL PRIVILEGES ON *.* TO rootlocalhost WITH GRANT OPTION; FLUSH PRIVILEGES;注意如果rootlocalhost已经存在执行CREATE USER会报重复错误此时应该用ALTER USER修改密码而不是重复创建。如果想把 host 从localhost改成%用RENAME USERRENAME USER rootlocalhost TO root%;不过说实话我不建议直接改 root 的 host 为%。root 这种超级账户能操作整个数据库如果允许任意主机远程连接一旦密码泄露整台服务器等于裸奔。更合理的做法是新建一个业务专用账号按需授权。5.4 更安全的替代方案新建专用账号如果业务场景需要从远程连接数据库我的习惯是创建专用账号而不是开放 root。示例CREATE USER app_user% IDENTIFIED BY App2024!Secure; GRANT ALL PRIVILEGES ON mydb.* TO app_user%; FLUSH PRIVILEGES;这条语句创建了一个只对mydb库有完整权限的账号允许从任意主机连接。如果只想让某个 IP 连接把%改成具体 IP 即可比如app_user192.168.1.100。这样做的好处很明显即使这个账号的密码泄露攻击者能影响的只有一个库不能动其他库和系统配置。权限隔离是数据库安全的底线也是很多事故复盘后得出的共同教训。5.5 修改权限表之前一定要做的事如果你决定直接操作mysql.user表我强烈建议先备份。毕竟手动修改系统权限表属于高风险操作一个 UPDATE 语句写错可能让整个 MySQL 无法正常认证。备份可以用 mysqldumpmysqldump -uroot -p mysql user user_backup.sql操作前备份操作后一旦发现不对劲可以用备份文件恢复。如果是通过 SQL 修改了 user 表记得执行FLUSH PRIVILEGES;让改动生效。这个细节很基础但很多人在UPDATE之后忘了刷新导致后续连接异常。6. Navicat、Workbench与程序连MySQL 8报1045的解决方案6.1 Navicat连接MySQL 8的典型插件问题Navicat 连接 MySQL 报 1045是我在社区和评论区看到频率最高的问题之一。症状是密码确认无误命令行能连上但 Navicat 始终报Access denied for user rootlocalhost (using password: YES)。这个问题的核心原因就是我在第 2 节提到的认证插件不兼容。MySQL 8 默认用caching_sha2_password而旧版 Navicat 只支持mysql_native_password。服务端用新方式加密密码客户端用旧方式解密两边握手失败最终表现为“密码错误”。解决办法有三种按优先级排列第一种升级 Navicat 到较新版本。新版 Navicat 已经支持 MySQL 8 的默认认证插件升级后问题自然消失。推荐这种方式因为它是让客户端跟上时代而不是让数据库降级。第二种把用户认证插件改成mysql_native_password。在 MySQL 命令行执行ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 你的新密码; FLUSH PRIVILEGES;注意MySQL 8.4 开始官方已经默认禁用mysql_native_password如果执行报错说明插件没启用。这种情况我建议用第一种方式升级客户端因为在新版本上强行启用旧插件有点开历史倒车。第三种新建一个指定旧插件的专用账号CREATE USER navicat_user% IDENTIFIED WITH mysql_native_password BY Navicat123; GRANT ALL PRIVILEGES ON *.* TO navicat_user%; FLUSH PRIVILEGES;然后 Navicat 用这个新账号连接。这个方式不修改 root 的状态也不影响其他客户端需要远程调试时特别好用。6.2 Workbench连接问题与解决思路MySQL Workbench 是官方出品的图形化客户端按理说不会出现插件兼容问题但一样有概率报 1045。常见原因有三个。第一个是 Workbench 里保存的密码是旧的缓存和服务器实际密码不一致。排查方式很简单在连接配置里把密码字段清空重新输入一次。别小看这个操作很多人因为“记住密码”功能长时间没手输过密码密码早就被改过自己却没更新配置。第二个是连接配置里的主机名或端口问题。Workbench 创建连接时默认localhost:3306如果你实际 MySQL 端口改动过需要同步修改。端口不对通常报 2003但如果配置里有代理或者中间件拦截了请求也可能表现为认证失败。第三个是权限表确实有问题。如果命令行也报 1045那就是前面章节讲的数据库侧问题按第 4、5 章的方法处理。6.3 Java应用连接MySQL 8的JDBC配置经验Java 项目连接 MySQL 8 报 1045除了密码问题外通常是驱动版本和连接串参数的问题。MySQL 8 对应的 JDBC 驱动是mysql-connector-java8.xMaven 依赖示例dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency连接串里有两个参数和 1045 问题高度相关。第一个是allowPublicKeyRetrievaltrueMySQL 8 的caching_sha2_password在非 SSL 连接下需要获取服务器的公钥来加密密码传输如果这个参数为 false客户端可能报Public Key Retrieval is not allowed。第二个是useSSLfalse。如果服务器没配置 SSL而连接串里设置了useSSLtrue认证过程中可能因为 SSL 握手失败导致连接中断报错信息有时会混合 1045 或通信异常。完整示例jdbc:mysql://127.0.0.1:3306/mydb?useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/ShanghaicharacterEncodingutf8如果项目用的还是老旧的 5.x 驱动连接 MySQL 8建议先升级。旧驱动用旧协议和老插件认证去连 MySQL 8 的默认认证插件几乎必然出问题。6.4 远程连接场景bind-address和防火墙的影响用 Navicat 或 JDBC 从另一台机器连接 MySQL 时还有一个经常被忽略的配置bind-address。MySQL 默认监听地址是127.0.0.1表示只允许本机连接。如果你在配置里看到bind-address 127.0.0.1那远程连接根本到不了 MySQL 服务端报错会是 2003无法连接而不是 1045。想要远程连接需要改成bind-address 0.0.0.0然后重启 MySQL。注意这种情况下账号的 host 字段也必须允许远程来源否则就会出现“网络通了但认证被拒”的 1045 报错。这就是我在第 5 章强调的host 匹配和网络监听是两个层面任何一层没对齐连接都建立不起来。防火墙安全组也要检查。Linux 的 firewalld、iptablesWindows 的防火墙还有云服务器的安全组只要拦了 3306 端口的入站流量远程连接一定会失败。如果端口不通优先查这些网络层面不要一直在密码上打转。7. 排查速查表与踩坑记录这些细节能省两小时7.1 常见现象与对应解决办法速查为了方便以后快速定位我把几种典型现象和对策整理成一张速查表你遇到问题时可以先对着表判断方向。现象可能原因解决方向命令行连不上报1045 using password YES密码确实错误确认输入无大小写/特殊符号问题必要时走重置流程命令行连不上报1045 using password NO客户端未传密码但账号要求密码使用-p参数并输入密码本机能连Navicat/Workbench连不上客户端版本老插件不兼容升级客户端或修改用户认证插件localhost能连127.0.0.1连不上host匹配问题检查user表中的host字段远程连接报1045账号host不允许远程或插件问题用user%账号并确保插件兼容输入密码后报1819密码不符合策略改复杂密码或临时调整密码策略改完密码重启后仍然1045skip-grant-tables残留或权限表未刷新检查配置文件、执行FLUSH PRIVILEGES这张表不能覆盖所有情况但覆盖了我见过的绝大多数问题。如果你发现自己的现象不在表里大概率是多个原因叠加了比如“密码既不对、host 也不匹配”这种时候按章节顺序逐个排查不要跳步。7.2 我踩过的几个坑密码重置的“后遗症”这里分享几个真实踩过的坑提醒大家避雷。第一个坑是修改完密码忘记关skip-grant-tables。有次我在测试环境用跳过认证的方式改密码改完直接开始业务验证发现执行某些 SQL 报权限错误排查了半天才想起配置里还留着那行开关。后来我把这个教训记成了习惯任何需要临时修改配置来救急的操作完成后第一件事就是恢复配置再验证结果。先复原则后验证这个顺序不能反否则后面所有测试结论都可能是错的。第二个坑是ALTER USER和FLUSH PRIVILEGES的使用时机。在跳过认证模式下如果先执行FLUSH PRIVILEGES再改密码某些版本可能出现“改完密码后跳过认证失效”的现象也就是紧接着就被拒之门外。我的建议是进入后先执行FLUSH PRIVILEGES再执行改密语句最后再执行一次FLUSH PRIVILEGES。中间多刷一次不费事但能避免很多版本差异带来的意外。第三个坑是密码里有特殊字符。比如密码是abc123在命令行直接写mysql -uroot -pabc123在 Linux 的 bash 环境里没有特殊含义还好但如果密码里有$、!、等符号shell 会按特殊字符处理导致传给 MySQL 的密码被截断连上去就报 1045。解决方式是一律用单引号包裹mysql -uroot -pabc$123或者更稳妥的方式是只输入-p不加密码让 MySQL 提示你输入避免 shell 层面的干扰。7.3 预防1045的几个日常工作习惯处理了这么多次 1045我总结了几条预防经验分享给大家。第一用配置文件管理连接信息不要到处手输密码。像.my.cnf这类客户端配置文件可以保存连接参数或使用 IDE 的连接管理工具密码只在配置时输入一次。这样能减少“记错密码”和“敲错密码”的概率。第二业务账号和 root 账号分开。开发用dev_user运维用root每个账号按最小权限授权。一旦发现账号异常只需要处理特定账号不会影响全局还容易定位问题源头。第三权限表变更保留审计记录。修改过哪个用户、执行过哪些 GRANT 语句都留一个记录文件。很多时候 1045 的根源是“上次某个人改了一下权限”如果没有审计记录排查时只能靠猜。第四定期备份。mysqldump导出的不仅是业务数据mysql库的权限表数据也值得定期备份。数据库账号体系一旦混乱有备份就能快速恢复省去重建账号和授权的时间。经验收尾排查1045时我的个人习惯最后分享一点个人的小习惯。每次遇到 1045我第一反应不是去重置密码而是先在命令行敲一条mysql -uroot -p试一下用最原始的方式把“密码错误”和“权限问题”分开。因为实践中相当比例的情况只是你把密码记混了或者客户端缓存了旧密码根本不需要动数据库设置。真正需要重置密码的只有明确知道“密码找不回来”这一条路。如果密码还记得但某台机器连不上先去查 host 匹配如果本地能连但客户端工具连不上先去查插件兼容如果远程连不上先去查网络监听和防火墙。按这个顺序排查大多数情况都能在十分钟内定位问题而不是一上来就把 MySQL 翻个底朝天。操作mysql.user表之前我也会先用 mysqldump 备份一份权限表数据。做这行越久我越觉得手里有备份心里不慌这句话比任何花哨的排查技巧都实在。
