MySQL 连接错误集锦

注：使用 ctrl + f 粘贴你的错误提示关键字，可快速定位该连接错误。

关于身份验证失败：

上方的错误提示码翻译成中文的大概意思是说：客户端不支持服务器请求的认证协议，考虑升级MySQL客户端。

那么，不妨换个思路想，有没有可能是服务器的协议与 MySQL 客户端的协议不同呢？
锁定关键字：认证协议。

继续思考下去，身份认证是连接的首要步骤，那么即可能是身份认证环节中出错了。
关键是，认证过程中发生了什么？我们编写的软件、服务器通过密码，或者是SSH之类的密令进行连接：是不是连接过程中密码错误或编码问题？
检查了配置是否启用 utf8 连接，结果是启用；

之后转到终端进行手动连接，我发现我可以正常进入，那么这个问题 Pass 掉
其实我对数据库的认识仅限于CURD，以及优化查询速度，但是对于深层原理只知悉一点，而我觉得问题应该出在 MySQL 里

这意味着我得进入 MySQL 的用户表看看密码长什么样子：
然后我发现了插件字段下的关于密码的字符串

（我已经修改了后面两个，起初都是 caching_sha2_password ）

其实我也不知道它们的意思，便只好去搜索引擎（bing）中查看对应的插件作用。

最后得知：MySQL 为了更安全的连接，将‘身份验证插件’升级了，且默认为 caching_sha2_password ，而大多数的服务器、软件中并没有内置相关协议。

也就导致了上方所述的错误代码了。

所以，为了兼容旧的服务器、软件的连接方式，我们可以修改关于此用户的身份验证协议。
比方：你想要让 root 用户在服务器中登录（通常不推荐这样做，只是比喻）
那么对应的修改方案如下：

# 修改身份验证插件为旧的加密方式,否则部分后台将无法连接
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password';
# 刷新
flush privileges;

（题外话）当然，建议创建一个用户，只具备查询权限，这意味着即使被服务器被暴力破解（我还有其它方法应对这个攻击方式），最坏的结果就是当前登录用户所连接的数据库数据泄露，不过重要字段都被加密，如手机号使用可逆加密，密码采用不可逆的加密方式；这样一来，短时间内应该可以反应过来。

# 创建新的用户 并指定使用旧的‘身份验证’
CREATE USER `test`@`localhost` IDENTIFIED WITH mysql_native_password BY 'test_password';

上方的错误翻译成中文，大概意思是说：用户XXX访问被拒绝

错误原因是：访问被拒绝，所以我们从访问的途径中来思考：

我分步了测试，大致如下：

由于在相同的时间段中，我创建了两个用户，所以我使用的测试一方案是：

使用两个不同的连接实例去连接数据库

结果是：第一个用户登录成功，第二个用户登录失败（即报错的那个）

不是字符编码的错，我还是挺相信自己写的服务器不会出现这种错误

方法：移出身份验证，再尝试连接：

直接就引发了：Client does not support authentication protocol requested by server; consider upgrading MySQL client；
这说明服务器是尝试连接的，也说明不是用户的问题。改回“旧的身份验证”继续测试

结果：成功登录

再修改回原来的密码，结果也是登录成功。

我们来总结下过程：

原用户 => 密码 123
登录时：密码 123；登录错误

删除用户，创建该用户继续尝试 => 密码 123
登录时：密码 123；登录错误

修改密码：abc
登录时：密码 abc；登录成功

修改回旧密码：123
登录时：密码 123；登录成功

再转到 user 表，看着 password 字段是加密的，那么如果 mysql 的登录过程中根据时间戳等来加密密码之后再进行 user 表比对，
那么 mysql 报出 访问被拒绝 也是意料之中。

而 Mysql 的用户管理极有可能存在缓存，因此即便删除，重新创建也会报出相同错误（猜测）。

更新密码后也更新了密码字段，所以原有密码也可以登录了。

这样就解释得通了，可是经常登录的为什么不会报错？
这个有待测试，我觉得 MySQL 会更新密码字段。当然仅仅是推测。