sql连接mysql数据库服务器失败，绝大多数情况是网络不通、账号权限受限或服务端配置问题这三件事引起的，按顺序排查，几分钟就能定位。
先分清报错类型，再动手排查
连接MySQL失败时，客户端给出的报错信息其实是很好的线索，不同报错对应不同原因，搞清楚了再下手,比瞎试强得多。
常见的报错大致分三类：
- 2003 Can’t connect to MySQL server：客户端压根没连到MySQL服务，网络、防火墙、服务没启动都在这个范围里。
- 1045 Access denied for user：网络通了，但账号密码错误或host限制,MySQL把你拒之门外。
- 10061 Connection refused：连接被主动拒绝,服务没监听端口或监听地址不对。
很多人一上来就改配置文件、重启服务，折腾半天发现是防火墙没放行，先把报错归类,能省一大半时间。
网络不通？从telnet这一步开始验证
navicat连接mysql报10061错误，先查这几项
用Navicat连不上MySQL是高频场景，报10061意味着目标服务器的3306端口根本没响应,按下面顺序查：
- 确认MySQL服务是否在运行，Linux上用
systemctl status mysqld或service mysql status，Windows打开服务管理器看MySQL服务状态，服务都没启动,后面全白搭。 - 检查端口监听，在MySQL服务器上执行
netstat -tlnp | grep 3306（Linux）或netstat -ano | findstr 3306（Windows），如果没有任何输出，说明MySQL没监听3306,问题在服务端配置。 - 本机telnet验证，在服务器本机执行
telnet 127.0.0.1 3306，能通说明MySQL本身没问题，问题出在外部访问链路；不通则问题出在MySQL自身。
mysql远程连接失败原因排查：从telnet说起
如果服务器本机能连、远程连不上，问题基本锁定在防火墙或云安全组，行业共识认为，远程连接失败有相当一部分是安全组规则没配置好,而不是MySQL本身出了问题。
- Linux防火墙：CentOS用
firewall-cmd --permanent --add-port=3306/tcp && firewall-cmd --reload
放行；Ubuntu用
ufw allow 3306/tcp。 - Windows防火墙：控制面板 → 防火墙 → 高级设置 → 入站规则,新建规则放行3306端口。
- 云服务器安全组：简米云、酷番云、华为云都在控制台里找“安全组”或“防火墙”入口，添加入方向规则，协议选TCP，端口填3306，来源设为允许访问的IP，别偷懒填
0.0.0/0,生产环境这等于裸奔。
这里有个细节容易被忽略：云服务器有两层防火墙，系统自带防火墙和云平台安全组都要放行3306,只放行一个照样连不上。
账号权限是mysql连接失败的隐形杀手
mysql access denied for user怎么处理
报1045错误时，网络链路没问题，是认证环节挂了,常见原因有三个：
- 密码确实错了，这个最尴尬，但也最常见，在服务器本机用
mysql -u root -p登录，能登进去就说明密码没问题,问题在远程访问的账号配置。 - host不匹配，MySQL的账号是由
user + host共同决定的。'root'@'localhost'和'root'@'%'是两个完全不同的账号，很多人在服务器本机用root用习惯了，以为远程也能用同一个账号连，其实远程连接需要的是'root'@'%'或'root'@'具体IP'。 - 加密插件不兼容，MySQL 8.0默认用
caching_sha2_password，老版本的Navicat或JDBC驱动不一定支持，连接报错Authentication plugin 'caching_sha2_password' cannot be loaded时，要么升级客户端，要么把账号改成mysql_native_password。
排查命令如下：
-- 查看账号和host的对应关系 SELECT user, host, plugin FROM mysql.user;
如果发现root只有localhost,那就创建一个允许远程访问的账号：
CREATE USER 'root'@'%' IDENTIFIED BY '你的密码'; GRANT ALL PRIVILEGES ON . TO 'root'@'%' WITH GRANT OPTION; FLUSH PRIVILEGES;
业内专家指出，直接改'root'@'localhost'
的host为有安全风险，更稳妥的做法是单独创建远程专用账号，按需授权,别一上来就给全部权限。
服务端配置把MySQL锁死在本地
bind-address把mysql锁在了本地
MySQL安装后的默认配置，相当一部分发行版会把bind-address设为0.0.1，意思就是只接受本机连接，外部IP访问直接被无视,表现就是连接超时或拒绝。
找到MySQL配置文件，Linux一般在/etc/my.cnf、/etc/mysql/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf，Windows在安装目录下的my.ini：
[mysqld] bind-address = 0.0.0.0
改成0.0.0表示监听所有网卡接口,改完重启MySQL：
systemctl restart mysqld
还有一种情况是配置了skip-networking，这会完全禁用TCP/IP连接，只能通过Unix socket本地访问，确认一下配置文件里有没有这个选项,有就注释掉。
云服务器mysql连接超时，安全组和防火墙各占一半
连接超时和连接拒绝本质不同，超时说明数据包发出去后没有响应，大概率是被防火墙或安全组静默丢弃了；拒绝则说明端口通但服务不认。
云服务器上遇到连接超时,排查顺序是：
- 云平台安全组：登录控制台，确认3306入方向规则是否放行，重点看来源IP是否包含你当前的公网IP，有些安全组规则写的是
/0，但云平台还有额外的“网络ACL”或“防火墙”策略,需要一并检查。 - 系统防火墙：用
systemctl status firewalld或ufw status确认防火墙状态,有些云镜像默认开着防火墙但没放行3306。 - MySQL监听地址：执行
netstat -tlnp | grep 3306，确认监听地址是0.0.0而不是0.0.1。
这三层每一层都有拦截的可能，层层排查下来基本能定位，需要特别注意的是，云服务器的安全组规则修改是即时生效的，但部分平台有短暂延迟,改完等十几秒再试。
驱动版本和连接参数也容易踩坑
用编程语言连接MySQL时,驱动版本和连接串参数同样会导致失败。
- JDBC连接MySQL 8.0：驱动版本必须用
mysql-connector-java8.0以上，连接串需要加serverTimezone=Asia/Shanghai，否则报时区错误，这个报错信息很直接，The server time zone value 'XXX' is unrecognized。 - Python连接MySQL：
pymysql和mysqlclient两个库对MySQL 8.0的支持不同，pymysql兼容性更好，连接时注意socket超时时间设置，默认值有时候太小,网络波动就断。 - PHP连接MySQL：PHP 7.x之后推荐用
mysqli扩展，mysql扩展早就移除了,用老代码连不上时先看是不是这个原因。
驱动版本问题还有个特征：同一个MySQL服务，Navicat能连、代码连不上，那就是驱动兼容性问题,而不是服务端配置问题。
快速定位的排查路径
压缩成一条可执行的排查路径：
| 步骤 | 操作 | 定位目标 |
|---|---|---|
| 1 | 服务器本机mysql -u root -p登录 |
MySQL服务是否正常 |
| 2 | 服务器本机telnet 127.0.0.1 3306 |
MySQL是否监听端口 |
| 3 | 远程telnet 服务器公网IP 3306 |
防火墙/安全组是否放行 |
| 4 | 查看mysql.user表的host字段 |
远程账号是否存在 |
| 5 | 检查my.cnf的bind-address |
是否限制监听地址 |
| 6 | 确认客户端驱动版本 | 是否兼容MySQL版本 |
按这个顺序走下来，多数情况下能在十分钟内定位问题，连接失败不怕,怕的是没有章法地乱试。
SQL连接MySQL失败，本质就是网络链路、认证授权、服务配置三者之一出了问题，从telnet验证网络开始，逐步检查账号权限和服务端监听配置，大多数问题都能快速解决，记住一个原则：先确认链路通不通，再谈账号和配置。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/602700.html
