晚上加班到十一点，数据库连不上了，屏幕上赫然跳出“1045 Access denied”。那一刻，我真想摔键盘。
这场景，干过开发、运维、甚至数据分析的朋友应该都不陌生。你用 Navicat 连接 MySQL，折腾了半天配置，用户名密码输了一遍又一遍，它就是不给面子。1045 这个错误码就像门神，站在你通往数据库的大门口，冷冷地告诉你：密码错了，或者，你没资格进来。
但很多时候，你明明记得密码是对的，甚至刚在其他终端用命令行连过，为什么在 Navicat 这里就翻脸了呢？别急，背后其实藏着一个常见的坑：MySQL 的密码验证机制变了，而 Navicat 这位老伙计，有时跟不上节奏。
MySQL 从 8.0 版本开始，默认的密码加密方式改成了 ，而 Navicat 的某些旧版本（比如 16 之前的）默认仍使用 。这就好比，你用一把新式钥匙去开一把老式锁，拧了半天，锁芯不匹配，门自然打不开。所以，看到的 1045 不一定是密码真的错了，而是 Navicat 用来验证密码的“语言”不对。
这时最直接的解决办法，就是让 MySQL 把该用户的密码验证方式改回 Navicat 能理解的 。操作并不复杂，但前提是你必须拥有能够通过命令行或其他客户端登录 MySQL 的权限。打开命令行工具，敲下下面的语句：
把引号里的内容换成自己的信息。例如，用户名是 root，主机是 localhost（本机连接），密码是 123456，则命令为：
敲完回车后，再执行 刷新权限，然后重新用 Navicat 连接。绝大多数情况下，问题就能解决。
当然，也有可能是你根本记不住密码，或数据库安装时生成了随机密码。这时需要先通过安全模式重置密码：关闭 MySQL 服务，使用 参数启动它，就可以无密码登录，再手动更新密码。虽然步骤稍繁琐，但属于数据库管理的基本功，值得掌握。
有些朋友会发现，改了密码验证方式后 Navicat能连了，但项目代码里用的 PHP、Python 或 Java 连接器仍报错。原因是旧版连接器同样不支持 。解决办法很简单：升级连接器到最新版，或在 MySQL 中把所有相关用户统一改回老的验证方式。如果公司有安全规范要求使用新式加密，就必须把连接器和 Navicat都升级到支持该加密的版本。直接装 Navicat 16 以上即可原生支持新加密方式，省去折腾。
还有一种情况纯粹是手误。比如在 Navicat 的连接配置里把端口写成了 3307，而 MySQL 实际跑在 3306；又或者主机名写成了 127.0.0.1，但 MySQL 只绑定了 localhost（Unix socket）。这些细节错误也会报 1045。排查时记得检查端口、主机、用户名、密码，每个字符都不能错。密码最好不要直接复制粘贴，防止带入不可见的空格或换行符。
如果以上方法都试过了，Navicat 仍然报 1045，就要考虑账户权限问题了。用命令行登录 MySQL，执行：
查看你的用户名是否存在，host 字段是否允许当前机器连接。比如数据库服务器 IP 是 192.168.1.100，但用户的 host 写的是 localhost，你从另一台电脑连，自然会被拒绝。这时可以新建一个允许远程连接的用户，或把 host 改成 （通配所有主机）。但在生产环境中把 host 改成 存在安全风险，建议按需设置。
说句实在话，1045 这个错误其实是个好老师。每一次遇到它，都是在提醒你：数据库连接不仅仅是填几个字段那么简单。用户名、密码、主机、端口、加密方式、权限表，这整套逻辑如果不清楚，迟早会在深夜被它暴击一顿。所以，与其每次百度搜索 “Navicat 连接数据库 1045”，不如花十分钟弄懂背后的原理。下次再看到这个错误码，你就不慌了，甚至还能帮同事解决，顺便收获一句 “大佬牛啊”。
对了，解决之后别忘了重启一下 Navicat，有时它会缓存旧的连接状态。关掉再打开，重新连一次。如果仍不行，就回到命令行，把所有步骤再走一遍。数据库不会骗人，只会给你最诚实的反馈。
