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';），比只看客户端报错靠谱得多。
