MySQL连接异常由网络、权限、配置、服务状态或客户端参数共同导致，应优先分析错误码：111（服务未启/端口被占）、1045（认证失败，含插件不兼容等）、2013（执行中断，多因超时或资源限制）、1129（IP被封），并结合日志定位。

MySQL 连接异常通常不是单一原因导致的，而是由网络、权限、配置、服务状态或客户端参数共同作用的结果。直接看错误码和提示比盲目重启更有效。

Connection refused（111）：服务根本没起来或端口被占

这是最典型的“连不上”，意味着 TCP 层就失败了，mysqld 进程未监听目标端口（默认 3306），或防火墙/安全组拦截了连接。

• 先确认服务是否运行：

  systemctl status mysql

  或

  ps aux | grep mysqld

• 检查端口监听：

  netstat -tlnp | grep :3306

  （Linux）；若无输出，说明服务没启动或配置了 skip-networking
• bind-address 配置为 127.0.0.1 时，远程无法连接；设为 0.0.0.0 或具体 IP 才允许外部访问（注意安全）
• Docker 容器中常见于没暴露端口：-p 3306:3306 缺失，或容器内 mysqld 启动失败后静默退出

Access denied for user（1045）：认证失败，但不等于密码错了

这个错误常被误判为“密码输错”，实际可能源于账号不存在、主机匹配失败、插件不兼容或密码过期。

• MySQL 8.0+ 默认使用 caching_sha2_password 插件，旧版客户端（如 MySQL 5.7 客户端、某些 JDBC 驱动）不支持，会报 1045 —— 解决方案是改用 mysql_native_password 认证：

  ALTER USER 'user'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd';

• 账号是 'user'@'localhost'，但你用 127.0.0.1 连，两者在 MySQL 中是不同主机 —— localhost 走 socket，127.0.0.1 走 TCP，需单独授权
• max_connections 耗尽也会触发类似拒绝行为，但错误码通常是 Too many connections (1040)，需检查 SHOW STATUS LIKE 'Threads_connected';

Lost connection to server during query（2013）：连接中途断开

不是连不上，而是连上后执行 SQL 时突然中断，多与超时、资源限制或网络抖动有关。

• wait_timeout 和 interactive_timeout 控制空闲连接存活时间，默认 28800 秒（8 小时），但中间件或云数据库常设得更短（如阿里云 RDS 默认 300 秒）—— 客户端需启用 autoReconnect=true（JDBC）或定期 ping
• 大结果集导致 max_allowed_packet 超限，服务端主动断连，错误日志里会有 Packets larger than max_allowed_packet 提示
• 客户端发起查询后，服务端因 OOM、kill 或崩溃退出，也会表现为 2013；可用 SHOW PROCESSLIST; 观察线程是否异常终止

Host is blocked（1129）：IP 被临时封禁

当某 IP 连续多次认证失败（默认 10 次），MySQL 会自动屏蔽该 IP，持续一段时间（由 host_cache_size 和底层行为决定）。

• 查看被封 IP：

  SELECT * FROM performance_schema.host_cache;

  （需开启 performance_schema）
• 清空缓存强制解封：

  FLUSH HOSTS;

  （注意：这会清掉所有缓存的主机信息）
• 长期方案是调大 max_connect_errors，或改用 fail2ban 等外部工具统一管控
• 云数据库（如腾讯云 CDB）可能把该机制升级为“安全组级封禁”，需去控制台手动解封

真正棘手的连接问题往往藏在日志里：务必打开 log_error 并检查 MySQL 错误日志路径（SHOW VARIABLES LIKE 'log_error';），比只看客户端报错靠谱得多。