MySQL远程连接四层关卡：配置、认证与排错实战

1. 场景拆解一次远程连接到底要过几道关“本地 mysql 连接远程服务器数据库”这件事我这些年被问过的次数少说也有大几十回。有的是刚把项目从本机搬到一台云主机上兴冲冲打开图形化客户端转了半天圈最后弹出一个 2003有的是团队把数据库从应用机器上拆出去做成独立的数据节点本地跑 Java 服务调试时直接连接超时还有的是新同事拿了账号密码本地怎么填都提示 Access denied最后发现账号后面的 host 压根不是他家的宽带出口 IP。这些问题的共同点是大家默认“数据库装好了、账号建好了、密码给对了”就等于“能连上”但远程连接实际上是一条要穿过四道关卡的链路任何一道关没打开表现都是“连不上”而错误码指向的位置完全不同。分不清关卡就只能靠猜——改配置、重启服务、重装客户端折腾一下午问题还在原地。这篇文章我按“关卡”来讲从服务端监听、账号门禁、认证握手、网络放行四个层面拆开再落到客户端的具体参数和连接池计算最后把我实际踩过的坑整理成一张排查表。适合刚接手远程数据库的新手也适合想把连接配置规范化、不再依赖“能跑就行”的老手。全程给的是可直接复制的命令和参数参数为什么这么设我也会说清楚。1.1 从 TCP 握手到认证完成中间隔着四层把一次远程连接拆开看客户端做的事其实很简单向host:3306发起一条 TCP 连接握手成功后发送账号、认证信息、目标库名服务端校验通过后返回 OK之后才开始收发 SQL。问题在于“握手成功后”这四个字之前的每一步都可能失败而失败原因分属四个完全不同的层。第一层是网络可达性。客户端的 SYN 包能不能到达服务器、服务器的 SYN-ACK 能不能回来。这一层挂掉客户端看到的表现是超时或者连接被拒绝MySQL 的错误日志里一个字都不会有因为它根本没收到连接。家庭宽带、公司出口防火墙、云厂商安全组、服务器本机防火墙都是这一层的关卡。第二层是 MySQL 的监听状态。服务进程必须真的在对外网卡上监听 3306。如果bind-address被设成127.0.0.1或者开了skip-networking那即使网络完全通畅你也照样连不上——因为进程压根没在对外地址上开耳朵。第三层是账号的 host 匹配。MySQL 的用户是用户名来源主机的组合不是单纯的用户名。同一个人从公司网连和从家里连来源 IP 不同可能匹配到两条完全不同的账号记录一条有权限一条压根不存在。第四层是认证握手。密码对不对、认证插件客户端支不支持、有没有强制 SSL 而客户端没开都在这一层判定。这一层的报错是最“像”密码错的所以最容易误判。我习惯按 1→4 的顺序排查因为越靠前越便宜网络层用一条 telnet 命令几秒钟就能判定而反复改密码可能要折腾半小时。1.2 三种常见拓扑先确定你属于哪一种不同拓扑下需要动的地方完全不一样先认清楚自己在哪一类能省掉一大半无效操作。同机房内网直连。应用和数据库在同一片内网通常是一个私有网段比如应用在10.0.0.20数据库在10.0.0.12。这种最简单不需要考虑公网暴露问题重点是账号的 host 段要覆盖应用所在网段防火墙放行内网段即可。绝大多数生产环境属于这一类。跨网段或办公网访问。开发者在自己工位上连测试环境的数据库。麻烦点在于办公网的出口 IP 经常是动态的NAT 之后一堆人共用一个出口账号 host 如果写死某个具体 IP第二天换了地址就连不上。这种情况我一般按出口网段授权或者在内网里放一台固定的跳转主机让所有人先登到那台机器再连库。公网直连。数据库直接监听在公网地址上客户端从任意位置连。坦白讲这是我极力不推荐的形态但原型阶段、临时演示确实常见。如果非做不可至少要做三件事账号只授权到具体来源 IP、改掉默认端口降低扫描噪音、强制 TLS。改端口不是安全措施只是让自动化扫描器少敲几次门别把它当护身符。确定拓扑之后后面所有的配置都有明确目标内网直连就把 host 段写清楚办公网访问就规划跳转主机公网直连就把加固措施一条条落实。最怕的是不知道自己在哪一类看到“改成 0.0.0.0 就能连了”就照做最后数据库挂在公网上被人跑字典。2. 服务端配置四个开关缺一不可服务端这边要动的地方不多但每一处都必须确认不能凭记忆默认“应该是开着的”。我见过太多案例是配置文件里改了一处、忘了另一处然后对着日志找半天。2.1 监听地址bind-address 决定 MySQL 听不听得见你先确认服务是不是真的在对外地址上监听。登录服务器root 或具备权限的账号执行SHOW VARIABLES LIKE bind_address; SHOW VARIABLES LIKE skip_networking; SHOW VARIABLES LIKE port;bind_address如果是127.0.0.1表示只监听本地回环外部一律连不进来。这里有个容易踩的认知偏差不同版本、不同发行版的默认值并不一致5.7 的多数安装包默认是127.0.0.18.0 的部分版本默认是*监听全部地址某些云厂商的镜像还会做二次修改。所以别查资料猜直接执行上面这条 SQL 看实际值这是唯一可靠的判断依据。skip_networking必须是OFF。这个参数一旦为ONMySQL 只走 Unix socketTCP 端口完全不监听表现就是端口扫描不通、但本地mysql -u root -p能进。这个参数一般只有极端安全场景才会开正常安装不会碰但接手别人环境时必须确认。要改的话找配置文件。Linux 上常见路径是/etc/my.cnf、/etc/mysql/my.cnfDebian 系通常在/etc/mysql/mysql.conf.d/mysqld.cnfWindows 是安装目录下的my.ini。在[mysqld]段落里加或改[mysqld] bind-address 0.0.0.0 port 33060.0.0.0表示监听所有 IPv4 地址。如果你的服务器有多张网卡只想让它监听内网那张直接写内网 IP 更精确比如bind-address 10.0.0.12这样公网网卡上就不会有 3306 的监听物理上少了一个暴露面。这个写法我很推荐成本为零收益明确。改完必须重启才生效systemctl restart mysqld # 或者 systemctl restart mysql重启后验证监听状态不要只看配置文件ss -lntp | grep 3306输出里应该能看到0.0.0.0:3306或者10.0.0.12:3306而不是127.0.0.1:3306。Windows 上用netstat -ano | findstr 3306看。注意改bind-address之前先想清楚这台机器有没有公网 IP。如果把它改成0.0.0.0并且安全组是全放通的等于把数据库直接摆在扫描器面前。改之前先把第 2.4 节的防火墙规则准备好顺序别反。2.2 账号来源 后面的 host 才是真正的门禁MySQL 的账号模型是userhosthost部分决定“从哪来的人可以用这条记录”。很多人建账号时习惯性写app%觉得这样省事结果就是把门禁拆了。先看现有账号是怎么配的SELECT user, host, plugin FROM mysql.user WHERE user app_rw;如果host那一列是localhost或者127.0.0.1那远程一定连不上因为你的连接来源不匹配。localhost在 MySQL 里有特殊含义走的是 Unix socket不是 TCP远程连接永远不会匹配到它。按用途建账号host 写来源网段CREATE USER app_rw10.0.0.% IDENTIFIED BY Str0ng#Passw0rd; GRANT SELECT, INSERT, UPDATE, DELETE ON shop.* TO app_rw10.0.0.%;这里10.0.0.%表示10.0.0.0/24这个网段。通配符只有两个%匹配任意长度字符_匹配单个字符。MySQL 不支持 CIDR 写法写10.0.0.0/24是无效的会当成字面量匹配结果就是谁也连不上——这个错误我见过不止一次。匹配规则要理解清楚MySQL 从mysql.user里挑匹配记录时优先选 host 最具体的。比如同时存在app_rw10.0.0.5、app_rw10.0.0.%、app_rw%三条从10.0.0.5来的连接会命中第一条。这个机制本身没问题但有个经典陷阱如果表里存在user为空字符串的匿名账号且它的 host 比你的账号更具体匿名账号会抢走匹配导致你用正确密码登录却报 Access denied。排查时顺手看一眼SELECT user, host FROM mysql.user WHERE user ;有匿名账号且不需要的话删掉DROP USER localhost;另外FLUSH PRIVILEGES这件事被过度神化了。用CREATE USER、GRANT、ALTER USER这类语句改权限MySQL 会自动刷新内存中的权限表不需要额外执行。只有当你直接UPDATE mysql.user表这种野路子操作时才需要。我建议永远不要直接改系统表8.0 之后权限表结构变了直接改很容易把账号搞坏。授权范围也要克制。应用账号只给业务库的 DML 权限不要图省事给ALL PRIVILEGES ON *.*。不给DROP、ALTER应用代码里的一个手滑就不会变成生产事故。需要建表改表的场景单独准备一个运维账号只在发布时使用。2.3 认证插件为什么密码明明对客户端还是登不上这是 8.0 之后出现频率陡增的一类问题。现象很迷惑用命令行mysql -h ... -u ... -p能进但本地老版本的驱动或客户端怎么都报 Access denied或者报一个关于caching_sha2_password的错。原因在认证插件。MySQL 8.0 把默认认证插件从mysql_native_password换成了caching_sha2_password新插件安全性更好但老版本客户端Connector/J 5.x、一些第三方 GUI 工具、旧版 ORM 驱动不认识这个握手协议。先看当前账号用的是什么插件SELECT user, host, plugin FROM mysql.user WHERE user app_rw; SHOW VARIABLES LIKE default_authentication_plugin;解决问题的正确顺序是先升客户端而不是先降服务端。因为caching_sha2_password的强密码校验和缓存机制确实更安全而降级插件等于把安全性退回几年前。把驱动升到 Connector/J 8.x、PyMySQL 1.x、各语言的主流新版本问题自然消失。如果确实有历史系统升不动再考虑给特定账号单独降级ALTER USER app_rw10.0.0.% IDENTIFIED WITH mysql_native_password BY Str0ng#Passw0rd;只对这一个账号降级别去改全局的default_authentication_plugin那会影响之后新建的所有账号。提醒mysql_native_password在新版本里已经被标记为废弃后续大版本会彻底移除。把它当作过渡手段别当成长期方案同时排上客户端升级的计划。还有一个和插件相关的参数值得知道caching_sha2_password在非加密连接上首次认证时需要客户端向服务端索取 RSA 公钥来加密密码传输。JDBC 里对应的是allowPublicKeyRetrievaltrue。这个参数打开意味着客户端会信任服务端给的公钥理论上存在中间人风险。所以我的建议是要么开 SSL 走加密连接要么用allowPublicKeyRetrieval两个都上当然更好但至少要有一个别在明文连接上既不加密又随便信任公钥。2.4 网络放行防火墙、安全组与端口服务端配置改完还有一道最容易被忽略的关卡防火墙。分两层本机防火墙和云厂商安全组两层的规则都要放行只开一层等于没开。本机防火墙CentOS/RHEL 系一般用 firewalld。开放整个网段比开放单 IP 更好维护firewall-cmd --permanent --add-rich-rulerule familyipv4 source address10.0.0.0/24 port port3306 protocoltcp accept firewall-cmd --reload firewall-cmd --list-allUbuntu/Debian 系常用 ufwufw allow from 10.0.0.0/24 to any port 3306 proto tcp ufw status verbose注意 ufw 的语法里from后面跟来源to any port指定目标端口写成allow 3306是全网放行别图省事。云厂商的安全组是独立的一套规则在控制台配置和本机防火墙互不影响。方向是“入方向”协议 TCP端口 3306源地址填客户端所在的网段。这里有个常被忽略的细节安全组的规则是有优先级的如果存在一条更靠前的全拒绝规则后面加的放行规则可能不生效配置完一定要在客户端实测别只看控制台显示的“已生效”。放行之后立刻验证# Linux / macOS nc -zv 10.0.0.12 3306 # 没装 nc 的话用这个 timeout 3 bash -c /dev/tcp/10.0.0.12/3306 echo port open # Windows PowerShell Test-NetConnection -ComputerName 10.0.0.12 -Port 3306nc返回succeeded说明 TCP 层已经通了。这一步非常关键它把“网络问题”和“MySQL 问题”彻底分开。端口不通就不用去看 MySQL 日志了端口通了再往下查账号和认证。我排查时永远先跑这一条能省掉大量无效翻日志的时间。3. 客户端实操从命令行到连接池服务端四道关都确认之后客户端这边其实很轻松。但客户端也有自己的坑尤其是连接参数和池子配置配错了不一定立刻报错可能跑几天之后在半夜出问题。3.1 命令行三段式验证法我不建议一上来就用图形化客户端连。图形工具会包装错误信息有时还会自动重试反而干扰判断。我习惯用三段式验证每段通过再进下一段。第一段端口可达。就是上面那条nc -zv。不通就回到第 2.4 节。第二段命令行登录。用真实账号连把参数写全mysql -h 10.0.0.12 -P 3306 -u app_rw -p --default-character-setutf8mb4-h指定主机-P指定端口大写 P小写 p 是密码提示-p后面不要紧跟密码让它交互式输入避免密码进 shell 历史。--default-character-setutf8mb4建议显式带上避免中文乱码排查时来回折腾。登进去之后立刻做几个确认SELECT USER(), CURRENT_USER(), hostname, port, VERSION(); SHOW STATUS LIKE Ssl_cipher;USER()返回的是你“声称”的身份CURRENT_USER()返回的是服务端实际匹配到的账号记录。这两个值不一样就说明匹配到的不是你预期的那条记录比如被匿名账号或者其他 host 更具体的记录截胡了。这个对比非常有用能直接定位到 2.2 节说的匹配问题。Ssl_cipher是空值表示当前连接是明文有值说明走了加密。第三段业务库和表能不能读。CURRENT_USER()对了不代表权限够再确认一下USE shop; SHOW TABLES; SELECT COUNT(*) FROM orders LIMIT 1;三段全过说明服务端配置没问题问题一定在应用侧的连接参数或驱动上。3.2 JDBC 与常见语言驱动的参数写法Java 项目用得最多把 URL 贴出来说清楚每个参数的作用jdbc:mysql://10.0.0.12:3306/shop?\ useUnicodetrue\ characterEncodingUTF-8\ sslModeREQUIRED\ serverTimezoneAsia/Shanghai\ connectTimeout3000\ socketTimeout60000\ allowPublicKeyRetrievaltrue\ rewriteBatchedStatementstrue逐个说characterEncodingUTF-8在 Connector/J 8.x 里会自动映射到utf8mb4这是支持 emoji 和部分生僻字的关键。5.x 时代需要写utf8但那实际上只对应三字节的utf8mb3存 emoji 会直接报错。这一点在社交、评论类业务里踩过的坑特别多。sslMode是 8.0.13 之后的新参数取值为DISABLED、PREFERRED、REQUIRED、VERIFY_CA、VERIFY_IDENTITY。老的useSSLtrue还能用但已废弃新项目直接用sslMode。内网可以先用PREFERRED跨网段建议REQUIRED。serverTimezone指定时区避免时间字段整体偏移 8 小时。较新版本的驱动能自动从服务端获取但显式写死更稳妥尤其是容器环境里默认时区经常是 UTC。connectTimeout是建立连接的超时单位毫秒。设 3000 比较合适太短在弱网下频繁失败太长会在数据库挂掉时把应用线程全部拖住。socketTimeout是读写超时。这个值要根据最慢的查询来定设太小会导致大查询被误杀设太大则慢查询会占着连接不放。rewriteBatchedStatementstrue是批量插入的性能开关它会把多条 INSERT 合并成一条多值语句实测批量导入场景下能差出好几倍。这个参数默认是关的很多项目压根没开。Python 用 PyMySQLimport pymysql conn pymysql.connect( host10.0.0.12, port3306, userapp_rw, passwordStr0ng#Passw0rd, databaseshop, charsetutf8mb4, connect_timeout3, read_timeout60, write_timeout60, ssl{ssl: True} )Go 的database/sql加go-sql-driver/mysqlDSN 写法dsn : app_rw:Str0ng#Passw0rdtcp(10.0.0.12:3306)/shop?charsetutf8mb4parseTimetruelocAsia%2FShanghaitimeout3sreadTimeout60s密码里有#、、:这类字符时DSN 里必须做 URL 编码否则解析会错位。这类问题报的错往往很含糊说是认证失败实际是密码被截断了。3.3 连接池参数怎么算为什么不能设太大连接池配大了是另一种形式的故障。很多人觉得“池子越大越能扛并发”结果数据库的连接数被打满反而整体变慢。先算一笔账。用利特尔法则同时在用的连接数 ≈ QPS × 单次操作的持有时长。假设业务峰值 QPS 是 500一条 SQL 平均执行 4 毫秒那同一时刻真正在跑的 SQL 只有500 × 0.004 2条。就算加上事务持锁、网络往返池子开 10 到 20 条足够。以 HikariCP 为例spring.datasource.hikari.maximum-pool-size15 spring.datasource.hikari.minimum-idle5 spring.datasource.hikari.connection-timeout3000 spring.datasource.hikari.idle-timeout600000 spring.datasource.hikari.max-lifetime1800000 spring.datasource.hikari.keepalive-time300000max-lifetime1800000是 30 分钟。这个值必须小于 MySQL 服务端的wait_timeout否则会出现“池子认为连接还活着服务端已经把它踢了”的情况表现就是间歇性的Communications link failure。MySQL 默认wait_timeout是 28800 秒8 小时看起来 30 分钟远小于它应该没事——但中间的网络设备NAT 网关、负载均衡、云厂商的弹性网卡空闲超时经常只有 300 到 900 秒。所以真正约束max-lifetime的往往不是 MySQL而是链路上的中间设备。我的经验值max-lifetime设 30 分钟keepalive-time设 5 分钟让池子定期给空闲连接发个心跳把中间设备的会话保活住。这一条解决过好几个查了很久的“半夜定时任务连不上库”的问题。maximum-pool-size的上限还要和服务端max_connections对齐。假设有 10 个应用实例每个池子 15 条那就是 150 条常驻连接服务端max_connections默认 151几乎贴着上限再加个运维工具连进来就爆了。要么把单实例池子调小要么把服务端上限提上去两边必须一起算。心得连接池不是越大越好池子过大还会掩盖连接泄漏。池子小的时候泄漏几条很快就会暴露池子大则可能撑几个月不报错等发现时已经积累了一堆僵尸连接。4. 报错排查实录六个最常撞上的坑错误码是排查的起点不是终点。同一个错误码在不同环境里成因可能完全不同下面这几类是我实际遇到频率最高的。4.1 ERROR 2003根本连不到端口完整报错长这样ERROR 2003 (HY000): Cant connect to MySQL server on 10.0.0.12:3306 (110)括号里的数字有讲究。110是 Connection timed out说明包发出去了但没有任何回应典型是防火墙静默丢包或者安全组没放行。111是 Connection refused说明目标主机可达但端口没在监听MySQL 没起或者bind_address只绑了回环。10060在 Windows 上对应超时10061对应拒绝。排查顺序固定下来别乱跳ping一下主机确认基本可达有些环境禁 ICMP不通不代表网络有问题看下一步nc -zv host 3306或Test-NetConnection确认端口不通就上服务器执行ss -lntp | grep 3306看进程在不在、绑的什么地址进程在但地址是127.0.0.1回到 2.1 节改bind_address地址对但仍不通查本机防火墙firewall-cmd --list-all/ufw status本机防火墙放行了还不通查云安全组全放行了仍不通抓包tcpdump -i any port 3306 -nn看在哪个方向断的第 7 步能用上的时候不多但一旦遇到通常是链路上有更隐蔽的设备在做过滤比如中间的网络策略设备。这时候抓包能看到 SYN 发出去了没有回应或者回应被丢了直接拿这个证据去找网络侧的人比空口说“我连不上”高效得多。4.2 ERROR 1130Host is not allowedERROR 1130 (HY000): Host 203.0.113.45 is not allowed to connect to this MySQL server这个报错信息量很大它告诉你服务端认为你来自哪个 IP。注意看203.0.113.45可能和你以为的出口 IP 完全不一样——如果你的客户端在 NAT 后面服务端看到的是 NAT 转换后的地址不是你本机的内网 IP。拿着这个 IP 去比对账号表SELECT user, host FROM mysql.user WHERE user app_rw;大概率是 host 段没覆盖到。比如你授权的是10.0.0.%但实际来源是10.1.0.%隔了一个网段。这种情况要么扩宽授权网段要么在中间加一台固定的跳转主机让所有人从同一台机器出去。还有一种情况是全表里压根没有这个用户名的记录那报错会是 1130 而不是 1045因为 MySQL 在匹配账号阶段就失败了。有些资料说“1130 就是权限没开”这话不准确——1130 是账号层面的 host 不匹配1045 才是认证层面的失败两者要分开处理。4.3 ERROR 1045Access deniedERROR 1045 (28000): Access denied for user app_rw203.0.113.45 (using password: YES)using password: YES说明密码是带了的NO说明压根没带密码比如-p后面输了个空。这两个要分开看。带了密码还失败四种可能密码真的错了。别笑占比最高。特别是有特殊字符时shell 里的$、!、#会被解释或者在配置文件里被转义。建议先ALTER USER重设一次用纯字母数字加两种符号的组合排除特殊字符干扰确认能连之后再换回复杂密码。账号的 host 匹配到了别的记录。用 3.1 节的USER()和CURRENT_USER()对比法确认。如果CURRENT_USER()显示的是app_rw%而你以为在用app_rw10.0.0.%说明匹配到了另一条记录那条的密码可能不一样。把冲突的记录找出来清理掉。认证插件不匹配。前面 2.3 节讲过8.0 的caching_sha2_password老客户端不认识。报错有时候会带Authentication plugin caching_sha2_password cannot be loaded有时候只是笼统的 Access denied得看服务端错误日志才清楚。服务端连不上认证源。这个少见一般出现在接了外部认证插件或者 LDAP 的场景先看错误日志再说。服务端的错误日志在SHOW VARIABLES LIKE log_error;指向的位置里面的记录比客户端报错详细得多包含具体是哪一步校验失败。排查 1045 时客户端报错和错误日志一定要对着看。4.4 ERROR 2013/2006连上了又断ERROR 2013 (HY000): Lost connection to MySQL server during query ERROR 2006 (HY000): MySQL server has gone away这两个是“连上了但中途断”。能连上说明网络、监听、账号都没问题断的原因通常是下面几种。包太大。max_allowed_packet限制单条 SQL 或单个结果集的大小。批量插入几千条数据、或者SELECT一个大的TEXT字段很容易超。查当前值SHOW VARIABLES LIKE max_allowed_packet;8.0 默认 64MB5.7 默认 4MB。差异很大从 5.7 升级上来的项目经常在这里翻车。客户端侧也要相应调整JDBC 里对应maxAllowedPacket参数两边的值要一致取小的那个生效。空闲超时被踢。这就是 3.3 节讲的wait_timeout和连接池max-lifetime的配合问题。服务端踢掉连接后客户端还拿着这个句柄去用就报 2013。解决办法是把max-lifetime压到wait_timeout和中间设备空闲超时的最小值以下再加个 keepalive。服务进程被杀。内存不足时被系统 OOM Killer 干掉或者运维手动重启。这种情况错误日志里会有明确的启动记录对一下报错时间点就能确认。网络抖动。跨网段、公网链路尤其明显。这种只能靠重试机制兜底应用层要有重连逻辑别指望连接永久可靠。4.5 能连上但特别慢DNS 反解与 host_cache这个现象很有迷惑性连接能成功但每次新建连接要卡两三秒之后查询飞快。原因在skip_name_resolve。这个参数为OFF时默认值MySQL 在收到连接后会拿客户端 IP 做一次反向 DNS 解析试图得到主机名好做更精细的 host 匹配。如果服务器的 DNS 配置有问题或者客户端 IP 没有 PTR 记录这一次解析要等超时几秒钟就没了。查一下SHOW VARIABLES LIKE skip_name_resolve;设为ON可以彻底关掉反解[mysqld] skip_name_resolve ON但有个副作用必须提前知道开了之后GRANT语句里的 host 部分不能用主机名只能用 IP 或者通配符。如果现有授权里有写主机名的记录比如appdb-client.example开了这个参数之后这些账号会全部失效。改之前先查一遍SELECT user, host FROM mysql.user WHERE host NOT REGEXP ^[0-9.%:_]$;确认没有主机名形式的授权或者先改成 IP 再开。另一个和连接数相关的表是performance_schema.host_cache缓存了每个客户端 IP 的连接统计和错误计数。这个表默认有大小上限IP 特别多比如公网直连、大量动态 IP时会被写满之后新 IP 的连接要频繁淘汰旧记录也会慢。查看和清理SELECT * FROM performance_schema.host_cache; TRUNCATE performance_schema.host_cache;顺带提一个相关的坑max_connect_errors默认 100某个 IP 连续失败超过这个数会被直接拉黑报ERROR 1129 (HY000): Host x.x.x.x is blocked because of many connection errors。应用配置写错、反复重试很容易在一分钟内攒够 100 次。清空host_cache表就能解封。也建议顺手把max_connect_errors调大一些比如 10000避免误伤。4.6 排查速查表把上面这些整理成一张表出问题时对着看比翻文档快报错/现象最可能的原因第一动作定位命令ERROR 2003 (110)防火墙或安全组未放行端口连通性测试nc -zv host 3306ERROR 2003 (111)MySQL 未启动或只绑回环看监听地址ss -lntp | grep 3306ERROR 1130账号 host 不匹配比对来源 IP 与授权记录SELECT user,host FROM mysql.userERROR 1045密码错、插件不匹配、匹配错账号对比USER()与CURRENT_USER()SHOW VARIABLES LIKE log_errorERROR 2013/2006包过大、空闲超时、进程被杀查max_allowed_packet与超时配置服务端错误日志ERROR 1129失败次数超限被拉黑清空 host_cacheTRUNCATE performance_schema.host_cache连接慢但能通DNS 反解或 host_cache 满开skip_name_resolveSHOW VARIABLES LIKE skip_name_resolve中文乱码字符集不是 utf8mb4检查库表与连接字符集SHOW VARIABLES LIKE character_set%这张表我一般直接贴在团队的排查文档里新人照着走一遍八成问题不用问人。剩下的两成通常涉及网络链路或者服务端资源那就得看具体的日志和监控了。5. 加固与长期维护别把 3306 直接丢在公网能连上只是开始接下来要让它长期可用、不出安全事故。远程数据库最常见的两类事故一类是被人扫到弱密码一类是连接参数没调好导致的间歇性故障。这两块都需要提前处理。5.1 账号规划与最小权限我的做法是一个应用一个账号一个环境一套账号。开发、测试、生产各用各的绝不共用一个root或者一个通用账号。这样出问题时看连接来源就能定位是哪个环境、哪个服务审计日志也好追溯。权限给到库级不给全局CREATE USER shop_order_svc10.0.1.% IDENTIFIED BY 随机生成的长密码; GRANT SELECT, INSERT, UPDATE, DELETE ON shop_order.* TO shop_order_svc10.0.1.%;需要跨库查询的场景逐个库授权不要图省事给*.*。需要建表权限的发布账号单独建只在发布窗口使用用完可以临时收回。只读账号和读写账号分开报表、BI 这类场景一律走只读账号。给只读账号的权限只有SELECTCREATE USER shop_report_ro10.0.2.% IDENTIFIED BY 另一个长密码; GRANT SELECT ON shop_order.* TO shop_report_ro10.0.2.%;密码策略这块8.0 自带validate_password组件可以强制长度和复杂度INSTALL COMPONENT file://component_validate_password; SET GLOBAL validate_password.policy MEDIUM; SET GLOBAL validate_password.length 12;装上之后设弱密码会直接被拒。这条对内网环境也建议开因为内网账号一旦被拿到横向移动的成本会低很多。还有一条经验给账号设置连接来源时优先写网段不写%。我知道有些人觉得办公网 IP 动态、写死了不方便但换个角度想%意味着任何能到达 3306 端口的人都有机会尝试而网段至少要求攻击者先进入那个网段。这个差别在真实攻防里很大。5.2 传输加密与审计跨网段或者跨越不可信网络的连接一定要开 TLS。MySQL 8.0 安装时会自动生成自签证书开箱可用。服务端强制要求加密[mysqld] require_secure_transport ON开了之后所有非加密连接会被拒绝客户端必须带 SSL 参数。JDBC 用sslModeREQUIRED如果要用证书校验完整性就用VERIFY_CA但需要把服务端 CA 证书导入客户端的信任库自签证书还要处理信任问题成本稍高。内网一般REQUIRED就够它保证了链路加密只是不验证服务端身份。验证是否真的走了加密SHOW STATUS LIKE Ssl_cipher; SHOW STATUS LIKE Ssl_version;返回非空就说明在加密。这个检查建议加到日常巡检里因为有些客户端配置会被悄悄覆盖或者换了驱动之后默认值变了。审计方面general_log能记录所有语句但开销很大只在排查期间临时开SET GLOBAL general_log ON; SET GLOBAL log_output TABLE; -- 排查完记得关 SET GLOBAL general_log OFF;长期审计用audit_log插件或者云厂商的数据库审计服务更合适对性能影响小得多。生产环境不建议长期开general_log磁盘会被快速写满而且写日志本身会拖慢所有查询。另外慢查询日志一定要开它是性能问题的第一手资料[mysqld] slow_query_log ON slow_query_log_file /var/log/mysql/slow.log long_query_time 1 log_queries_not_using_indexes ONlong_query_time 1是阈值超过 1 秒的记录下来。这个值根据业务调整OLTP 系统可以设到 0.5 秒报表系统设 5 秒更合理。log_queries_not_using_indexes会把没走索引的查询也记下来前期很有用但索引优化到位之后建议关掉否则日志会膨胀得很快。5.3 参数调优与日常巡检远程连接相关的几个参数值得定期看一眼参数默认值建议说明max_connections151按实例数 × 池大小 20 冗余留出运维工具连接的余量wait_timeout28800600~1800缩短可加快僵尸连接回收interactive_timeout28800与 wait_timeout 一致交互式连接的超时max_allowed_packet64M8.0/4M5.764M 或按业务定批量写入场景重点看connect_timeout105~10握手超时别设太小max_connect_errors10010000防止误拉黑skip_name_resolveOFFON消除连接慢的常见原因wait_timeout调小有个好处链路断开后的僵尸连接能更快被服务端回收不会一直占着max_connections的名额。但也不能太小比如设成 60 秒长事务场景下正常连接会被误杀。600 到 1800 秒是比较舒服的区间和连接池的keepalive-time配合起来正好。巡检我一般做成一个脚本每天跑一次重点看几项-- 当前连接数与上限 SHOW STATUS LIKE Threads_connected; SHOW VARIABLES LIKE max_connections; -- 连接失败统计 SHOW GLOBAL STATUS LIKE Aborted_connects; SHOW GLOBAL STATUS LIKE Connection_errors_%; -- 慢查询数量 SHOW GLOBAL STATUS LIKE Slow_queries; -- 是否有长时间空闲连接 SELECT id, user, host, command, time, state FROM information_schema.processlist WHERE command Sleep AND time 600 ORDER BY time DESC;Aborted_connects这个指标特别值得盯。它统计的是握手阶段就失败的连接数持续增长说明有人在尝试连接但失败了——可能是配置错的应用在重试也可能是外部在扫。配合Connection_errors_%系列指标能区分是认证失败、host 被拒还是超时。这几个数字安静的时候说明一切正常突然抬头就说明有事发生。那个查空闲连接的 SQL 我也常年在用。看到一堆Sleep状态超过 10 分钟的连接基本可以断定是连接池的max-lifetime没配好或者某个应用的连接泄漏了。清理这些连接本身不安全KILL掉可能导致应用报错但看到这个信号就该去查应用侧的池子配置了。最后分享一个我自己养成的小习惯每次给一个新环境配好远程连接之后我会把完整的配置过程写成一份清单存档——bind_address改成了什么、账号 host 写的是哪个网段、防火墙开了哪条规则、客户端 URL 长什么样。看着啰嗦但下次迁移环境或者交接给别人的时候照着清单十分钟就能复现一遍比凭记忆重新摸一遍要省太多事。而且清单本身就是一份排查基线出问题时逐条对照很快就能找出是哪一项被改动了。