MySQL 连接错误集锦 - 长期更新
连接的错误无非几点：身份验证失败、没有权限访问、用户访问被拒绝、用户不存在（目前遇到）
注：使用 ctrl + f 粘贴你的错误提示关键字，可快速定位该连接错误。
关于身份验证失败：
Client does not support authentication protocol requested by server; consider upgrading MySQL client；
上方的错误提示码翻译成中文的大概意思是说：客户端不支持服务器请求的认证协议，考虑升级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';
关于用户访问被拒绝错误
Access denied for user 'xxx'@'localhost' (using password: YES)
上方的错误翻译成中文，大概意思是说：用户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 会更新密码字段。当然仅仅是推测。
