# 保哥笔记 — MySQL > 本分片含 4 篇文章，按发布日期倒序。全部分片索引见 https://zhangwenbao.com/llms-full.md **站点**：https://zhangwenbao.com/ **分类**：MySQL **生成**：2026-06-04 23:09:29 CST --- ## MySQL用户管理完全手册：8组核心命令实战指南 - URL：https://zhangwenbao.com/mysql-creates-users-authorizes-revoke-privileges-and-removes-user-commands.html - 分类：MySQL - 发布：2017-03-10 | 更新：2026-06-02 - 摘要：完整覆盖MySQL用户管理的8组核心命令：建用户、授权、撤销、删除、改密、锁定、踢会话、审计。每组都配MySQL 5.7和8.0语法差异说明，ssl_cipher报错的解决方案，K8s和RDS场景的host字段配置策略，以及如何用information_schema跑出权限健康度报告。 - 关键词：MySQL命令,MySQL权限管理,MySQL用户,数据库安全,GRANT语法 > **TLDR**：摘要：MySQL的用户管理离不开八组核心命令。本文先讲清用户与权限模型，再逐组给建用户、授权、撤销、删除与会话强制踢除、改密码与权限的完整命令清单，每组配5.7与8.0的语法差异，再讲ssl_cipher报错的解决、K8s与RDS下host字段的配置、五个真实生产事故复盘，以及用information_schema跑权限健康度报告。 > 摘要：MySQL的用户管理离不开八组核心命令。本文先讲清用户与权限模型，再逐组给建用户、授权、撤销、删除与会话强制踢除、改密码与权限的完整命令清单，每组配5.7与8.0的语法差异，再讲ssl_cipher报错的解决、K8s与RDS下host字段的配置、五个真实生产事故复盘，以及用information_schema跑权限健康度报告。 保哥从2010年代开始就一直在用MySQL，这些年带过不少新人，发现MySQL用户管理是大家最容易出错也最容易留下安全隐患的一块。表面上就那几条CREATE USER、GRANT、REVOKE、DROP USER命令，但里面的坑细究下来不少：5.7和8.0语法不一样、localhost和%行为完全不同、FLUSH PRIVILEGES什么时候要执行什么时候不需要、REVOKE撤完了还能登录是怎么回事。这篇我把日常运维里高频用到的MySQL用户管理命令完整梳理一遍，配上自己踩过的坑和验证方法，方便需要的朋友照着用。 ## 理解MySQL的用户与权限模型 开始动手之前，先把概念理清楚，后面踩坑会少很多。 MySQL的用户标识是user加上host这一对组合，不是单纯的用户名。也就是说test@localhost、test@192.168.1.10、test@%这三个是完全独立的账号，可以分别设置不同的密码和不同的权限。host字段支持以下几种写法： - localhost：仅允许本机通过Unix Socket登录 - 127.0.0.1：仅允许本机通过TCP回环登录 - 192.168.1.10：仅允许这一个具体IP - 192.168.1.%：允许192.168.1.0/24整个网段 - %：允许任意IP（生产环境慎用） 保哥的经验是：host越窄越安全。除非真的没办法预知客户端IP，否则不要写%。在阿里云RDS、腾讯云CDB这类托管数据库上，安全组已经做了第一层网络过滤，但MySQL层面的host限定仍然是必要的纵深防御。 关于权限的存储位置，MySQL 5.7及之前是mysql.user、mysql.db、mysql.tables_priv、mysql.columns_priv四张表分别管理全局、库级、表级、列级权限。MySQL 8.0新增了mysql.global_grants用来管理动态权限（如BINLOG_ADMIN、ROLE_ADMIN），传统的SUPER权限被拆分成多个细粒度动态权限。理解这套表结构，遇到权限疑难杂症时直接SELECT这些表就能定位问题。 ## 创建用户的完整命令清单 登入MySQL： mysql -u root -p 标准创建语法： -- 仅本机可登录 CREATE USER 'test'@'localhost' IDENTIFIED BY 'Test@2024Pass'; -- 指定 IP 可登录 CREATE USER 'test'@'192.168.7.22' IDENTIFIED BY 'Test@2024Pass'; -- 指定网段可登录 CREATE USER 'test'@'192.168.7.%' IDENTIFIED BY 'Test@2024Pass'; -- 任意 IP 可登录 CREATE USER 'test'@'%' IDENTIFIED BY 'Test@2024Pass'; MySQL 8.0指定认证插件：MySQL 8.0默认用caching_sha2_password，部分老客户端不兼容，可以显式指定： -- 显式使用兼容性更好的插件 CREATE USER 'legacy_app'@'%' IDENTIFIED WITH mysql_native_password BY 'LegacyPass!23'; -- 显式使用更安全的插件（默认） CREATE USER 'modern_app'@'%' IDENTIFIED WITH caching_sha2_password BY 'ModernPass!23'; 创建用户时的常见报错。保哥遇到过最坑的一个错：ERROR 1364 (HY000): Field 'ssl_cipher' doesn't have a default value。这个错通常出现在升级过的MySQL 5.6或5.7实例上，mysql.user表结构异常。我的处理流程是： # 1. 编辑 my.cnf 或 my.ini，找到 sql-mode # 原来： sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION" # 改成： sql-mode="NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION" # 2. 重启 MySQL sudo systemctl restart mysql 如果还不行，那就是mysql.user表本身需要upgrade： sudo mysql_upgrade -u root -p ## 授权语法骨架与场景化模板 用户建好之后默认是没有任何库表权限的，连SHOW DATABASES都看不全。需要单独GRANT。 GRANT语法骨架： GRANT 权限列表 ON 数据库.表 TO '用户'@'host'; 常见的权限列表： -- 全部权限 GRANT ALL PRIVILEGES ON quant.* TO 'test'@'localhost'; -- 业务系统通常只需 CRUD GRANT SELECT, INSERT, UPDATE, DELETE ON quant.* TO 'test'@'localhost'; -- 只读账号 GRANT SELECT ON quant.* TO 'reader'@'%'; -- 备份账号 GRANT SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER, RELOAD, REPLICATION CLIENT ON *.* TO 'backup'@'localhost'; -- 管理账号（带 GRANT OPTION，可以再向下分授权） GRANT ALL PRIVILEGES ON *.* TO 'dba'@'10.0.0.5' WITH GRANT OPTION; MySQL 5.7 vs 8.0语法差异。MySQL 5.7允许GRANT ... IDENTIFIED BY一行搞定建用户加授权： -- 5.7 可用，8.0 报错 GRANT ALL ON quant.* TO 'test'@'localhost' IDENTIFIED BY '123'; MySQL 8.0必须先CREATE USER再GRANT： -- 8.0 推荐分两步 CREATE USER 'test'@'localhost' IDENTIFIED BY 'Test@2024'; GRANT ALL ON quant.* TO 'test'@'localhost'; 保哥写脚本时统一按8.0写法来，可以兼容5.7（5.7也支持分两步），反过来不行。 FLUSH PRIVILEGES什么时候要执行。这是新手最容易迷惑的点。规则其实很简单：用CREATE USER、GRANT、REVOKE、DROP USER、SET PASSWORD、ALTER USER这些正规账号管理语句，不需要FLUSH PRIVILEGES，MySQL会自动重载权限。直接用INSERT、UPDATE、DELETE改mysql.user等系统表，必须FLUSH PRIVILEGES才能生效。现在还在生产环境直接UPDATE mysql.user的人不多了，所以多数场景其实可以省掉这条。但加上也无害，写脚本时为了保险我都会加： FLUSH PRIVILEGES; ## 撤销权限的全场景对照 REVOKE是GRANT的反操作，语法对称： -- 标准格式 REVOKE 权限列表 ON 数据库.表 FROM '用户'@'host'; -- 撤销具体权限 REVOKE INSERT, UPDATE, DELETE ON quant.* FROM 'test'@'localhost'; -- 撤销所有权限 REVOKE ALL PRIVILEGES ON quant.* FROM 'test'@'localhost'; -- 撤销 GRANT OPTION（管理权限） REVOKE GRANT OPTION ON *.* FROM 'dba'@'10.0.0.5'; -- 一次撤销账户的全局所有权限 REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'test'@'localhost'; 一个常见的迷惑。保哥经常被问：我REVOKE了，为什么test用户还能登录？答：REVOKE撤的是数据库或表权限，不是登录权限。MySQL中只要mysql.user表里有这个user加host记录，密码对就能登录，只是登录后什么也看不到、什么也干不了。要彻底禁止登录，得用DROP USER或者ALTER USER ... ACCOUNT LOCK。 -- 锁定账户（保留账号但禁止登录，8.0 支持） ALTER USER 'test'@'localhost' ACCOUNT LOCK; -- 解锁 ALTER USER 'test'@'localhost' ACCOUNT UNLOCK; ## 删除用户与会话强制踢除 确认账号不再使用了，就直接删掉： -- 删除单个账号 DROP USER 'test'@'localhost'; -- 一次删多个 DROP USER 'test'@'localhost', 'test'@'192.168.7.22', 'test'@'%'; -- 删除前先确认账号存在 SELECT user, host FROM mysql.user WHERE user = 'test'; 注意DROP USER不会断开当前已经连上的会话。如果有人正在用这个账号操作数据库，连接会一直保留到他自己断开为止。要立刻踢人，可以： -- 找出该用户的所有会话 ID SELECT id, user, host, db, command, state FROM information_schema.processlist WHERE user = 'test'; -- 把对应的会话 KILL 掉 KILL 12345; ## 修改密码与权限的常用操作 顺手把日常会用到的几个补全，这样就是一个完整的运维手册： -- 修改自己的密码（任何用户都能改自己的） ALTER USER USER() IDENTIFIED BY 'NewPass@2024'; -- root 改某个用户的密码 ALTER USER 'test'@'localhost' IDENTIFIED BY 'NewPass@2024'; -- 强制用户下次登录改密码 ALTER USER 'test'@'localhost' PASSWORD EXPIRE; -- 设置密码 90 天过期 ALTER USER 'test'@'localhost' PASSWORD EXPIRE INTERVAL 90 DAY; -- 重命名用户 RENAME USER 'old_name'@'localhost' TO 'new_name'@'localhost'; -- 查看某用户的所有授权 SHOW GRANTS FOR 'test'@'localhost'; -- 查看当前登录用户的授权 SHOW GRANTS; ## 5个真实生产事故复盘 这一节保哥拿过去这几年帮客户处理过的5个真实MySQL用户管理事故出来对照，让你看到“命令会用”和“不出事故”之间的距离。 事故一：root账号被全网爆破。某做跨境电商的客户，MySQL实例直接暴露在公网3306端口，root@%账号开了远程登录，密码强度还可以但抵不住分布式扫描。两周内被尝试登录127万次，最终在某个晚上被撞库成功，整库被加密勒索。事后保哥介入做的第一件事就是DROP root@%，关闭3306公网访问，root只保留root@localhost。 事故二：业务账号被多个微服务复用。某SaaS客户的应用层有8个微服务，全部用同一个app@%账号连MySQL，权限是ALL PRIVILEGES ON saas.*。某次开发同事写错了一段DELETE脚本误删了几千条订单数据，事后想从binlog反推是哪个微服务执行的，但所有连接都是同一账号根本无法区分。解决方案是按微服务拆分账号app_order@%、app_user@%、app_payment@%等，再开慢日志和审计插件。 事故三：DBA离职没回收权限。某游戏公司DBA离职后2个月，他的私人IP仍然能通过dba@public_ip连进生产库做SELECT。被发现的时候他已经SELECT了用户表27次，幸好没有泄漏外部。补救措施是建立离职checklist，HR确认离职当天必须DROP所有相关账号，且每月跑一次SELECT user, host FROM mysql.user对照在职名单审计。 事故四：FLUSH PRIVILEGES漏跑导致权限不生效。某团队用脚本批量改了mysql.user表的plugin字段（从mysql_native_password改成caching_sha2_password），但忘了FLUSH PRIVILEGES，结果新登录的客户端还在用老插件认证，部分应用层报1045错误。教训是绝对不要直接UPDATE系统表，要改用ALTER USER语法。 事故五：GRANT OPTION滥用引发权限蔓延。某客户的运维同事给所有DBA都开了WITH GRANT OPTION，结果一位DBA把app@%账号也加了GRANT OPTION，应用层程序通过SQL注入 (https://zhangwenbao.com/dedecms-membership-center-pm-php-injection-vulnerability-repair-method.html)漏洞拿到了app账号，然后用GRANT OPTION给自己提权到root级别。修复办法是收回所有非DBA管理员的GRANT OPTION，且业务账号绝不允许任何GRANT权限。 ## 权限审计SQL与监控视图 除了知道命令怎么用，更重要的是建立审计机制。保哥分享几条日常巡检会跑的SQL。 列出所有具有DBA级别权限的账号： SELECT grantee, privilege_type FROM information_schema.user_privileges WHERE privilege_type IN ('SUPER','GRANT OPTION','CREATE USER','RELOAD','SHUTDOWN','PROCESS','FILE') ORDER BY grantee; 找出所有host为%的账号（潜在风险）： SELECT user, host, authentication_string, account_locked FROM mysql.user WHERE host = '%' ORDER BY user; 统计每个账号的当前会话数（看看哪些账号活跃）： SELECT user, host, COUNT(*) AS conn_count FROM information_schema.processlist GROUP BY user, host ORDER BY conn_count DESC; 查找30天没登录过的账号（结合general log或慢日志反向定位）： -- MySQL 8.0 起有 performance_schema 可以辅助 SELECT user, host, last_login FROM mysql.user WHERE password_last_changed < DATE_SUB(NOW(), INTERVAL 90 DAY); 保哥建议把这4条SQL封装成存储过程或者定时任务，每周生成一份权限健康度报告，方便审计追溯。配合企业微信或飞书机器人推送，运维同事手机上就能看到当周权限变化。 ## 生产环境用户管理的最佳实践 保哥这几年经手的项目里，用户管理出问题往往不是命令不会用，而是没有规范。结合多次审计经验，给几条建议： - 一个业务一个账号。不要让多个服务共用一个数据库账号，出问题排查不出谁干的。 - 最小权限原则。业务账号只给业务库的CRUD，不给DDL；监控账号只给PROCESS、REPLICATION CLIENT；备份账号只给只读加LOCK TABLES。 - host精确到IP。即使有K8s这种动态IP场景，也尽量精确到Pod网段，比如'app'@'10.244.%'。 - 密码进密钥管理服务。不要把密码写在代码、配置文件、镜像里，用Vault、KMS、阿里云Secrets Manager这类工具管。 - 定期审计mysql.user。每个季度跑一遍SELECT user, host FROM mysql.user，把不再使用的账号DROP掉。 - root@%永远不要存在。这个是被扫描器爆破的头号目标，发现立刻删。 ## 常见问题解答 ## CREATE USER之后必须FLUSH PRIVILEGES吗 不必须。CREATE USER、GRANT、REVOKE、DROP USER等账号管理语句会自动重载权限。只有当你直接UPDATE系统表（如mysql.user）时，才需要FLUSH PRIVILEGES。MySQL 5.7和8.0行为完全一致，写脚本时不需要为了兼容性强制加FLUSH。 ## 为什么我创建了test@%还是连不上 先确认MySQL是否监听了远程地址（bind-address (https://zhangwenbao.com/configuration-method-of-remote-connection-mysql.html)），再检查防火墙和云安全组。MySQL用户授权只是认证层，前面还有网络层。另外MySQL在认证时会按host的精确度匹配，如果同时存在test@localhost和test@%，本机连接会命中前者，密码不匹配就连不上。可以用mysql -h 127.0.0.1这种IP方式强制走TCP而不是Unix Socket，绕过localhost的匹配。 ## REVOKE ALL之后用户为什么还能登录 因为REVOKE撤的是库表权限，不是登录权限。要禁止登录用ALTER USER ... ACCOUNT LOCK；要彻底删除用DROP USER。LOCK的好处是保留账号信息（包括密码、host、过期时间），未来如果要恢复，UNLOCK一下就行；DROP是彻底删除，恢复要重新建。 ## MySQL 8.0用Navicat 11连不上怎么办 八成是认证插件不兼容。把账号的认证插件改成mysql_native_password：ALTER USER user@host IDENTIFIED WITH mysql_native_password BY pass； 或者升级Navicat (https://zhangwenbao.com/navicat-10-1-7-registration-code.html)到12以上版本。MySQL Workbench 8.0以上、DataGrip 2019.3以上、HeidiSQL 11.0以上都原生支持caching_sha2_password，没必要为了一个老GUI让全公司密码插件降级。 ## 如何批量把所有账号的密码插件从mysql_native_password改成caching_sha2_password 不要直接UPDATE mysql.user表，会出问题。标准做法是用一条SQL生成ALTER USER脚本：SELECT CONCAT(ALTER USER ', user, @, host, ' IDENTIFIED WITH caching_sha2_password BY ', password, '; ') FROM mysql.user WHERE plugin = mysql_native_password。把生成的脚本人工review后逐条执行。注意密码要从应用层重新分发，因为新插件用了新的哈希算法，老密码不会自动迁移。 ## K8s场景下host字段应该怎么配 K8s的Pod IP是动态的，但Pod所在网段是固定的。最常见的方案是给业务账号配Pod CIDR对应的网段host，比如app@10.244.%。如果使用Calico等CNI且开启了Network Policy，可以进一步限制只允许特定namespace的Pod访问数据库，这是更纵深的防御。也可以用ServiceAccount + Vault动态生成短期数据库账号（每小时轮换），这是云原生最佳实践但落地成本较高。 ## 写在最后 MySQL用户管理不是高深技术，但一个公司数据库的安全防线第一道就建立在这里。保哥的建议是把这套命令写成模板，每次新建账号都从模板生成，host段、权限范围、密码策略全部规范化，用一年以后你会发现安全事件少了一大半。技术不是壁垒，规范才是。最后再强调一句：所有用户管理操作都要在审计日志里留痕，事后可追溯，这比任何防御技术都更重要。 ## 权威参考资料 ## MySQL远程连不上？从bind-address、授权到防火墙三层打通 - URL：https://zhangwenbao.com/configuration-method-of-remote-connection-mysql.html - 分类：MySQL - 发布：2017-03-07 | 更新：2026-06-02 - 摘要：详解MySQL 5.7和8.0远程连接配置实战，覆盖bind-address改0.0.0.0或内网IP、CREATE USER分两步授权、caching_sha2_password兼容性、防火墙与云安全组放行、SSL加密五道防线的完整步骤与生产真实踩坑案例。 - 关键词：远程连接,Navicat,MySQL,bind-address,数据库授权 > **TLDR**：摘要：MySQL远程连不上通常卡在三层。本文按三层防线打通——第一层改bind-address让MySQL监听外网、第二层给用户授权远程登录权限并处理caching_sha2_password兼容、第三层放行防火墙与云安全组的3306端口，再加SSL加密这道防线，配五个典型生产场景的连接方案、四道安全防线和三个真实踩坑案例。 > 摘要：MySQL远程连不上通常卡在三层。本文按三层防线打通——第一层改bind-address让MySQL监听外网、第二层给用户授权远程登录权限并处理caching_sha2_password兼容、第三层放行防火墙与云安全组的3306端口，再加SSL加密这道防线，配五个典型生产场景的连接方案、四道安全防线和三个真实踩坑案例。 ## 写在前面：远程连不上MySQL的三类根因 保哥这些年帮朋友搭过不少业务系统，最常遇到的踩坑场景之一就是：本地开发好好的，部署到云服务器以后用Navicat (https://zhangwenbao.com/navicat-10-1-7-registration-code.html)或者DBeaver连不上MySQL。报错通常是这三类里的一种：客户端卡半天显示Can't connect to MySQL server on '...' (10060)，或者立刻弹Host '...' is not allowed to connect to this MySQL server（1130），又或者TCP连上之后报Access denied for user 'root'@'1.2.3.4' (using password: YES)（1045）。这三个错误的根因完全不同，处理顺序也不一样，但很多教程混在一起讲，结果排查时绕大圈。 这篇文章保哥把自己整理多年的远程连接配置流程从头梳理一遍，覆盖配置文件修改、用户授权、权限校验、防火墙、SSL加固、审计监控七个层面，给需要在生产或测试环境开启远程访问的朋友一个可以照着抄的清单。文章里所有命令保哥都在Ubuntu 22.04 + MySQL 8.0.34、CentOS 7 + MySQL 5.7.42、Debian 11 + MySQL 8.0.36三套环境上实测过，差异点会单独标出。 先建立一个心智模型：远程连接MySQL要打通三层防线——网络层、认证层、权限层。任何一层出问题都会拒绝你，但拒绝的方式不一样，识别清楚拒绝的形式比盲目改配置高效十倍。下面这张表是保哥这几年总结的错误信号识别清单，可以照着对号入座。 错误码或现象 | 所在层 | 本质原因 | 优先排查方向 | 2003 / 10060 卡10秒以上超时 | 网络层 | TCP握手失败，包根本没到MySQL | bind-address (https://mariadb.com/kb/en/server-system-variables/) + 防火墙 + 云安全组 | 2003 立刻返回 Connection refused | 网络层 | 端口到了但没人监听 | MySQL是否启动、bind是否为127.0.0.1 | 1130 Host is not allowed | 认证层 | mysql.user表里没匹配的host行 | CREATE USER + GRANT (https://mariadb.com/kb/en/grant/) 配host通配 | 1045 Access denied (using password: YES) | 认证层 | 密码错或认证插件不匹配 | 密码核对 + caching_sha2 (https://mariadb.com/kb/en/authentication-plugin-sha-256/)兼容性 | 1698 Access denied (using password: NO) | 认证层 | auth_socket插件强制用OS账号 | 改用mysql_native_password或caching_sha2 | 2059 Authentication plugin not loaded | 认证层 | 客户端不认caching_sha2_password | 升级客户端或ALTER USER改回native | 1142 SELECT command denied | 权限层 | 用户已认证但缺具体表权限 | GRANT具体权限到具体库表 | 按照"网络层先通、认证层再通、权限层最后细化"的顺序排查，95%的远程连接问题都能在15分钟内定位。剩下5%通常是云厂商的奇葩限制（比如阿里云RDS的SSL强制开关、AWS RDS的Parameter Group覆盖默认配置），这种属于厂商限制，文末会单独提。 ## 第一层：bind-address让MySQL监听外网 MySQL进程默认只监听127.0.0.1:3306，外部TCP SYN包根本进不到MySQL进程，客户端表现就是卡10秒超时（2003或10060）。要让MySQL监听其他网卡，必须改bind-address这个配置项。 ## 不同发行版的配置文件路径 找到MySQL的[mysqld]段是第一步，但不同发行版下路径差别巨大，下面是保哥实战遇到过的所有位置： - Debian / Ubuntu (MySQL 5.7+ / 8.0)：/etc/mysql/mysql.conf.d/mysqld.cnf - 老版本Ubuntu (16.04及更早)：/etc/mysql/my.cnf - CentOS 7 / RHEL 7：/etc/my.cnf - CentOS 8+ / RHEL 8+：/etc/my.cnf.d/mysql-server.cnf - MariaDB on Debian：/etc/mysql/mariadb.conf.d/50-server.cnf - 宝塔面板 (https://zhangwenbao.com/bt-panel-upgrade-failed.html)安装：/etc/my.cnf，但实际生效的可能是/www/server/mysql/etc/my.cnf，看symlink - Docker (https://zhangwenbao.com/wordpress-docker-containerized-deployment-environment-consistency.html)镜像：/etc/mysql/my.cnf，但通常通过环境变量或挂载conf.d覆盖 不知道哪个文件生效，可以连上MySQL执行SHOW VARIABLES LIKE 'bind_address';查看当前值，然后用mysqld --help --verbose 2>&1 | grep -A1 'Default options'列出MySQL启动时按顺序读取的所有配置文件，最后那个文件里的设置优先级最高。 ## bind-address的5种典型写法 找到[mysqld]段下面的bind-address = 127.0.0.1，按需要改成以下任一种： [mysqld] # 监听所有IPv4地址（最常见，但攻击面最大） bind-address = 0.0.0.0 # 监听所有IPv4和IPv6 bind-address = * # 监听指定的内网网卡IP（保哥强烈推荐） bind-address = 10.0.0.5 # MySQL 8.0.13+ 支持多地址监听 bind-address = 127.0.0.1,10.0.0.5 # 仅监听本机回环（默认值，不允许任何远程连接） bind-address = 127.0.0.1 保哥的最佳实践是：能绑内网IP就绝对不要绑0.0.0.0。阿里云、腾讯云、AWS这种带内网网卡的环境，应用服务器和数据库走内网，bind-address写内网IP（用ip addr看本机的内网eth1或bond0地址），公网根本扫不到3306端口，省掉一半攻击面。如果业务一定要从公网连，那就配合云安全组白名单只放固定办公IP，并强制SSL加密。 改完之后重启MySQL服务： # systemd管理的发行版 sudo systemctl restart mysql # Ubuntu / Debian sudo systemctl restart mysqld # CentOS / RHEL # 老的SysV风格 sudo service mysql restart # 宝塔面板 /etc/init.d/mysqld restart 验证监听是否到位，用ss命令（保哥推荐，比netstat快）： sudo ss -tlnp | grep 3306 # 输出应该是： # LISTEN 0 70 0.0.0.0:3306 0.0.0.0:* users:(("mysqld",pid=1234,fd=21)) # 或者绑内网IP的： # LISTEN 0 70 10.0.0.5:3306 0.0.0.0:* users:(("mysqld",pid=1234,fd=21)) 如果ss看到的还是127.0.0.1:3306，说明配置文件改的不是生效的那一份，或者重启没成功。重启时如果MySQL启动失败，去看/var/log/mysql/error.log，常见原因是配置文件语法错误（比如bind-address那行多了空格或者重复定义）。 ## bind-address改完后立刻做的3件事 - 本机telnet自测TCP通不通。在MySQL所在服务器执行telnet 10.0.0.5 3306，应该立刻看到5.7.42-log\C... mysql_native_password这种banner信息，说明MySQL已经在该IP上监听并欢迎握手。 - 从外部主机telnet确认网络层通。在你打算连接MySQL的客户端机器上执行telnet 10.0.0.5 3306或者nc -zv 10.0.0.5 3306。如果这一步通不了，那是网络问题（防火墙、安全组、路由），跟MySQL配置无关，先解决网络再回来。 - 抓包确认握手成功。必要时在服务器上tcpdump -i any -nn host 客户端IP and port 3306 -X，看TCP三次握手是否完整、有无RST包。生产排查中这一步往往能直接定位是云安全组拦了还是MySQL没监听。 ## 第二层：用户授权配置远程登录权限 TCP握手通了之后，MySQL会根据用户的host字段判断这个客户端IP是否被允许登录。如果你的账户是'root'@'localhost'，从192.168.1.10来连接就会被拒绝，错误码1130（Host is not allowed）。这里的host是认证层的关键字段，理解它的匹配规则是用对GRANT语句的前提。 ## mysql.user表的host字段匹配规则 MySQL在认证时，会按以下优先级匹配mysql.user里的host字段： - 完全匹配：'admin'@'10.0.0.5'，只允许10.0.0.5这一个IP登录 - IP段通配：'admin'@'10.0.0.%'，允许10.0.0.0到10.0.0.255这一段 - 掩码格式：'admin'@'10.0.0.0/255.255.255.0'，等效于上面的通配 - 主机名匹配：'admin'@'web01.example.com'，需要MySQL能反向DNS解析 - 全通配：'admin'@'%'，所有外网IP都能登 - 本机专用：'admin'@'localhost'，只走UNIX socket（不经过TCP） 这里有一个非常容易踩的坑：'admin'@'localhost'和'admin'@'127.0.0.1'在MySQL里是两个独立的账户，不是一个。前者走UNIX socket，后者走TCP回环。两者可以有不同的密码、不同的权限。线上经常出现"本地用客户端连得上，但程序用TCP连不上"的情况，根因就是只建了localhost账户没建127.0.0.1的。 ## MySQL 5.7 和 8.0 的GRANT语法差异 登入MySQL： mysql -u root -p MySQL 5.7的写法（可以一行带IDENTIFIED BY）： -- MySQL 5.7：CREATE和GRANT可以合并 GRANT ALL PRIVILEGES ON *.* TO 'admin'@'%' IDENTIFIED BY 'StrongPass!2024' WITH GRANT OPTION; FLUSH PRIVILEGES; MySQL 8.0的写法（必须分两步，老语法直接报错）： -- 第一步：CREATE USER CREATE USER 'admin'@'%' IDENTIFIED BY 'StrongPass!2024'; -- 第二步：GRANT GRANT ALL PRIVILEGES ON *.* TO 'admin'@'%' WITH GRANT OPTION; FLUSH PRIVILEGES; 如果在8.0上误用5.7的合并写法，会直接报ERROR 1064 (42000): You have an error in your SQL syntax，因为IDENTIFIED BY子句在GRANT里已经被废弃。这个变化是8.0最容易让从5.7升级过来的运维栽跟头的地方之一。 ## 生产环境的细粒度权限授权 保哥强烈不建议在生产环境给业务账号ALL PRIVILEGES ON *.*。一个业务系统通常只需要操作自己那个库，授权过宽等于一旦账号泄露就全库沦陷： -- 业务账户只授权单库的CRUD权限 CREATE USER 'app_blog'@'10.0.0.%' IDENTIFIED BY 'AnotherStrongPass!'; GRANT SELECT, INSERT, UPDATE, DELETE ON blog.* TO 'app_blog'@'10.0.0.%'; -- 只读账户（报表、BI、灾备从库连接） CREATE USER 'reporter'@'10.0.0.%' IDENTIFIED BY 'ReadOnlyPass!'; GRANT SELECT, SHOW VIEW ON blog.* TO 'reporter'@'10.0.0.%'; -- DBA账户（带GRANT OPTION，但限定跳板机IP） CREATE USER 'dba'@'10.0.99.10' IDENTIFIED BY 'DBAStrongPass!'; GRANT ALL PRIVILEGES ON *.* TO 'dba'@'10.0.99.10' WITH GRANT OPTION; FLUSH PRIVILEGES; 这里'10.0.0.%'表示只允许10.0.0.0/24这一段内网过来的连接，比'%'安全得多。'10.0.99.10'则是把DBA权限锁死到一台运维跳板机，即使密码泄露，攻击者也必须先入侵跳板机才能登MySQL。 ## 密码插件：caching_sha2_password的兼容性陷阱 MySQL 8.0 把默认认证插件从mysql_native_password换成了caching_sha2_password。这个改变带来一个直接后果：很多老客户端连不上，报错Authentication plugin 'caching_sha2_password' cannot be loaded（错误码2059）。常见的不支持caching_sha2的客户端包括： - Navicat 11及更早版本 - PHP 7.1及以下的mysqlnd驱动 - Python pymysql 0.9及更早 - Java MySQL Connector/J 8.0.10及更早 - Go database/sql的go-sql-driver/mysql v1.4及更早 有两种解决思路。第一种是升级客户端到支持caching_sha2的新版本，长期看这是正解。第二种是把账号改回mysql_native_password，过渡期用： ALTER USER 'admin'@'%' IDENTIFIED WITH mysql_native_password BY 'StrongPass!2024'; FLUSH PRIVILEGES; 也可以在[mysqld]段全局改默认值，让新创建的账号都用native： [mysqld] default_authentication_plugin = mysql_native_password 注意MySQL 8.0.34之后这个参数被authentication_policy取代，新写法： [mysqld] authentication_policy = mysql_native_password ## 校验授权是否生效 授完权一定要查一下，不要默认它生效了。保哥每次都习惯性核对： -- 1. 查看所有账户和host SELECT user, host, plugin FROM mysql.user; -- 2. 查看指定用户的具体权限 SHOW GRANTS FOR 'admin'@'%'; -- 3. 查看当前连入的会话 SHOW PROCESSLIST; -- 4. 查权限是否细到单表（5.7+ 8.0均可） SELECT * FROM information_schema.user_privileges WHERE grantee LIKE "'admin'%"; SELECT * FROM information_schema.schema_privileges WHERE grantee LIKE "'admin'%"; SELECT * FROM information_schema.table_privileges WHERE grantee LIKE "'admin'%"; 执行SHOW GRANTS应该看到类似： +-----------------------------------------------------------------------+ | Grants for admin@% | +-----------------------------------------------------------------------+ | GRANT ALL PRIVILEGES ON *.* TO `admin`@`%` WITH GRANT OPTION | +-----------------------------------------------------------------------+ ## 第三层：防火墙与云安全组放行3306 MySQL监听了、用户也授权了，外面还是连不上，十有八九是防火墙或云安全组没放。这一层最坑爹的地方是：本地服务器防火墙、云厂商安全组、可能还有运营商的网络层ACL，这三层任何一层拦截都会表现为客户端连接超时，但日志上看不出区别。 ## 本机操作系统防火墙 Ubuntu默认用ufw，CentOS 7+用firewalld，老服务器或者裸机可能直接用iptables。三套放行写法： # Ubuntu (ufw) sudo ufw allow from 10.0.0.0/24 to any port 3306 sudo ufw allow from 192.168.99.10 to any port 3306 # 指定跳板机 sudo ufw status numbered # CentOS / RHEL (firewalld) sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.0.0/24" port port="3306" protocol="tcp" accept' sudo firewall-cmd --reload sudo firewall-cmd --list-all # 通用 (iptables) sudo iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 3306 -j ACCEPT sudo iptables -A INPUT -p tcp --dport 3306 -j DROP # 兜底，其他来源全拒 sudo iptables-save > /etc/iptables/rules.v4 # Debian系统持久化 sudo service iptables save # CentOS 注意iptables规则顺序敏感：ACCEPT必须写在DROP前面，否则全部包先匹配到DROP就被丢了，ACCEPT永远轮不到。 ## 云厂商安全组放行 云厂商安全组（阿里云的安全组规则、腾讯云的安全组、AWS的Security Group）也要在控制台同步放行。保哥见过太多次：服务器防火墙都关了，结果还是连不上，最后发现是VPC安全组拦着。任何时候排查云上端口连通性，都要把云安全组当作第一道防线检查。 各家云厂商的配置位置： - 阿里云：ECS控制台 → 实例 → 安全组 → 配置规则 → 入方向 → 添加3306端口、授权对象填客户端IP段 - 腾讯云：CVM → 实例 → 安全组 → 入站规则 → 新增TCP 3306的允许策略 - AWS：EC2 → Security Groups → 选实例所属SG → Edit Inbound Rules → 添加MySQL/Aurora类型 - 华为云：ECS → 实例 → 安全组 → 入方向规则 - UCloud：UHost → 防火墙 → 添加3306的TCP允许规则 本地用telnet或nc验证TCP端口能不能通： telnet 服务器公网IP 3306 nc -zv 服务器公网IP 3306 nmap -p3306 服务器公网IP # 更详细，能看出filtered还是closed nmap结果里的状态含义： - open：端口监听中，能正常握手，问题转向认证层 - filtered：包被防火墙静默丢弃（典型的SYN包被DROP，没有RST响应） - closed：服务器有响应但没人监听这个端口（典型的MySQL没启动） ## SSH隧道：不开公网3306的连法 保哥强烈推荐的做法是根本不要把MySQL端口暴露到公网，而是通过SSH隧道访问。命令行下： ssh -L 13306:127.0.0.1:3306 user@服务器公网IP 这条命令在本机起一个13306端口，所有发到本机13306的流量都通过SSH隧道转发到远程服务器的127.0.0.1:3306。然后本地客户端连127.0.0.1:13306就等同于连远程的MySQL。优点：MySQL不用开公网监听、不用配置远程账户的高强度密码、SSH本身有密钥认证更安全、流量自动加密。 Navicat也支持SSH隧道：连接配置里勾选"SSH"标签页，填上SSH服务器、端口、用户、密钥文件，主连接的主机就填127.0.0.1。这是保哥给客户做开发支持时100%采用的方式。 ## 5个典型生产场景的远程连接方案 ## 场景一：开发机直连云数据库 团队规模在3到10人时，常见做法是开发本地直连测试环境的MySQL。这种场景下推荐的配置：MySQL bind到内网IP、云安全组只放公司公网IP段（或团队VPN出口IP）、每个开发员独立账号、host限定到办公网段。不允许使用共享账号，否则离职审计、权限回收都没法做。 ## 场景二：跳板机走SSH隧道访问 团队规模超过20人或者合规要求严的金融、医疗行业，必须走跳板机。架构是：所有人先SSH到跳板机（带双因子认证），再从跳板机连MySQL（内网直连）。MySQL的mysql.user里DBA账号host写跳板机内网IP，普通开发不直接连DB，通过审计工具CloudQuery或Bytebase代理。 ## 场景三：容器化部署连Docker MySQL Docker里跑MySQL的场景比较特殊，主要注意两点：第一，Docker默认网络模式是bridge，容器内的127.0.0.1是容器自己的回环，不是宿主机。要让外部连进来，docker run时必须-p 3306:3306把容器端口映射到宿主机。第二，MySQL镜像里的bind-address默认就是0.0.0.0（因为容器内本来就是隔离的），所以不用改配置。但root账号默认只允许从localhost连，需要建一个'root'@'%'账号或者用环境变量MYSQL_ROOT_HOST=%。 ## 场景四：读写分离从库远程访问 从库远程访问的典型用途是给BI、数据分析、灾备查询。配置注意点：从库的复制账号必须有REPLICATION SLAVE权限、外部访问的只读账号只GRANT SELECT、不要在从库上做任何写入（否则会破坏复制一致性）、监控从库的Seconds_Behind_Master，远程查询时检查这个值小于30秒再用，否则数据滞后会导致BI报表口径错。 ## 场景五：多机房主从复制 主从跨机房复制本质上也是远程连接，主库要允许从库的IP登录复制账号： CREATE USER 'repl'@'10.1.0.%' IDENTIFIED BY 'ReplPass!'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.1.0.%'; 跨机房复制必须走专线或VPN，不能裸跑公网。一是数据安全（binlog里全是明文SQL，能解出敏感数据），二是延迟（公网延迟波动会导致复制延迟飙升）。如果实在没有专线，至少配MASTER_SSL=1把复制通道走SSL加密。 ## 4道生产环境安全防线 ## 防线一：最小权限原则 账号权限永远按"用什么给什么"配置。具体到MySQL： - 业务读写账号：GRANT SELECT, INSERT, UPDATE, DELETE ON db.* 即可，不要给DROP、ALTER、CREATE - 报表只读账号：GRANT SELECT, SHOW VIEW ON db.* 即可 - 备份账号：GRANT SELECT, RELOAD, REPLICATION CLIENT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER ON *.*（mysqldump需要） - 禁止任何业务账号带GRANT OPTION，否则可以创建其他高权限账号 - root账号严格本地登录，远程管理用独立DBA账号 ## 防线二：强密码 + 定期轮换 密码至少16位混合字符（大写、小写、数字、特殊字符），不要明文写死在代码里，用环境变量或密钥管理服务（Vault、阿里云KMS、AWS Secrets Manager）。线上密码90天轮换一次，开发测试环境密码与生产严格隔离。MySQL 8.0支持密码过期策略： -- 90天后密码强制过期 ALTER USER 'admin'@'%' PASSWORD EXPIRE INTERVAL 90 DAY; -- 密码策略：最少16位、必须含数字大小写特殊字符 SET GLOBAL validate_password.policy = STRONG; SET GLOBAL validate_password.length = 16; ## 防线三：SSL连接加密 MySQL 8.0默认支持SSL，但需要在客户端主动启用。检查服务端SSL状态： SHOW VARIABLES LIKE '%ssl%'; SHOW STATUS LIKE 'Ssl%'; 客户端连接时加上SSL参数： # 命令行 mysql -h db.example.com -u admin -p --ssl-mode=REQUIRED # JDBC连接串 jdbc:mysql://db.example.com:3306/blog?useSSL=true&requireSSL=true&verifyServerCertificate=true # Python pymysql pymysql.connect(host='db.example.com', user='admin', password='...', ssl={'ca': '/path/to/ca.pem'}) 账户级强制SSL（用户必须用SSL连接才能登录）： ALTER USER 'admin'@'%' REQUIRE SSL; ## 防线四：审计日志 开启general_log或安装audit_log插件，定期看有没有异常登录尝试。general_log会记录所有SQL，性能开销大，生产环境推荐只开slow_log + 失败连接日志： [mysqld] # 慢查询日志 slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 1 # 记录失败连接（5.7+） log_warnings = 2 更严格的方案用MySQL Enterprise的audit_log插件或开源替代品Percona的audit_log_plugin，能记录每一次登录尝试、每一条执行的DDL，方便事后审计。 ## 3个生产真实踩坑案例 ## 案例一：忘记FLUSH PRIVILEGES导致间歇性认证失败 某客户上线一个新业务，DBA创建账号后没执行FLUSH PRIVILEGES，结果上线后部分应用连得上、部分连不上。排查到最后发现：MySQL在内存里缓存了权限信息，新建的账号没被刷到缓存，应用根据连接池里的连接行为不一致。修复方法：FLUSH PRIVILEGES立即生效。教训：CREATE USER + GRANT 之后必须FLUSH PRIVILEGES，写脚本时把它放在GRANT后面固定收尾。 ## 案例二：caching_sha2_password导致PHP 7.0业务全线挂掉 从MySQL 5.7升级到8.0之后，所有用PHP 7.0连接的业务全部报2059错误。临时方案：把所有业务账号ALTER回mysql_native_password，业务恢复。长期方案：把PHP升级到7.4+，driver自动支持caching_sha2_password。教训：MySQL大版本升级前必须先评估所有客户端的driver兼容性，写一份client compatibility matrix再动手。 ## 案例三：bind到0.0.0.0被公网爆破10万次 某测试服务器图省事bind到0.0.0.0，安全组只放了开发IP但加了一个0.0.0.0/0临时规则忘删，三天后扫描日志显示3306被扫了10万次，其中有8000多次尝试用弱密码登录。所幸root密码够强没被打穿，但已经触发安全告警。教训：任何时候bind 0.0.0.0必须配合白名单云安全组使用，0.0.0.0/0的安全组规则坚决不留。修复后改为bind内网IP + SSH隧道访问，再没遇到爆破。 ## 常见问题解答 ## 改完bind-address重启后，连接报1130 Host is not allowed，是怎么回事？ 说明TCP已经通了，是认证层拦的。检查mysql.user表里目标用户的host字段，确保它能匹配你的客户端IP。最常见的就是只建了'user'@'localhost'没建'user'@'%'或'user'@'10.0.0.%'，把后者补上即可。注意CREATE USER之后必须FLUSH PRIVILEGES，否则MySQL内存里的权限缓存不更新，新建账号要等到下次MySQL重启才生效。如果通过SHOW GRANTS看到账号是对的、host也匹配，但还是1130，看看是不是连了别的MySQL实例（多实例环境下端口可能不是3306）。 ## 为什么MySQL 8.0我用Navicat老版本连不上，提示caching_sha2_password错误？ MySQL 8.0把默认认证插件从mysql_native_password换成了caching_sha2_password，老客户端不支持。三种解决思路：第一升级Navicat到Premium 12.1或更新版本，原生支持caching_sha2；第二在MySQL服务端把账号改回native插件，执行ALTER USER 'admin'@'%' IDENTIFIED WITH mysql_native_password BY '密码'；第三在my.cnf里把default_authentication_plugin改成mysql_native_password，让新建的账号都默认走native。生产环境保哥优先推第一种，根本解决问题；运维过渡期用第二种。 ## 我已经有了'root'@'localhost'，再GRANT 'root'@'%'安全吗？ 保哥强烈不建议。root账号权限最大，一旦被爆破后果灾难。生产环境请新建独立的远程管理账号（比如admin或dba），host限制为运维跳板机内网IP，root永远只允许本地登录。如果你已经创建了'root'@'%'，立刻执行DROP USER 'root'@'%';删掉。一个更隐蔽的风险：很多镜像安装时默认给root设置了空密码或者弱密码，再加上bind 0.0.0.0，等于把数据库门钥匙放在公网门口。 ## bind-address写了0.0.0.0，但我只想让特定几个IP能连，怎么办？ bind-address控制的是监听网卡，不能精细到来源IP级别。要做白名单有两条路：一是在MySQL用户授权时把host锁死成具体IP（CREATE USER 'admin'@'1.2.3.4'）；二是依靠操作系统防火墙或云安全组的来源IP规则（iptables或安全组只放1.2.3.4到3306）。生产环境推荐两层都加，纵深防御——MySQL层把host写死，防火墙层把来源IP也限制，即使任一层被绕过另一层还能兜底。 ## 用Navicat测试连接通过但程序连不上，可能是什么原因？ 这是个典型场景，保哥见过五六次。原因通常是这几类：第一程序用的是连接池，连接池里的旧连接还在用变更前的认证状态；第二程序连的是localhost而MySQL只建了'user'@'127.0.0.1'账号（localhost走UNIX socket、127.0.0.1走TCP是两套）；第三程序所在容器/服务器的网络出口IP和你Navicat测试的IP不是同一个，授权的host没覆盖到；第四程序的字符集/SSL/认证方式与Navicat不一致。排查顺序：先看程序错误日志的具体错误码，再用程序所在机器手动跑mysql命令行验证，最后对比Navicat和程序的连接参数差异。 ## 我连接成功但执行SELECT报1142 SELECT command denied是怎么回事？ 已经过了认证层，卡在权限层。账号能登录但没有具体库表的SELECT权限。执行SHOW GRANTS FOR CURRENT_USER();看当前账号的权限明细，确认是否对目标库有SELECT。如果只授权了某个库，访问其他库就是1142。修复：用DBA账号执行GRANT SELECT ON db_name.* TO 'user'@'%';然后FLUSH PRIVILEGES。另一种隐蔽情况是授权用了反引号`db_name`但库名实际包含特殊字符或大小写不一致，导致授权和实际库不匹配，这种用SHOW DATABASES核对库名再GRANT。 ## 云数据库RDS的远程连接和自建MySQL有什么不一样？ RDS本质上还是MySQL，但有几个限制：第一bind-address参数被云厂商锁死，用户不能改；第二root账号被云厂商收回，给用户的是一个高权限子账号（阿里云叫"高权限账号"，腾讯云叫"管理员"）；第三防火墙不是OS层的，而是RDS控制台里的"白名单"或"安全组"；第四SSL证书由云厂商签发，用户下载即可。配置远程连接的步骤：进RDS控制台 → 数据安全性 → 白名单添加客户端IP → 申请外网地址（如果需要公网访问，注意公网访问通常有额外计费）→ 创建账号并授权 → 客户端用外网地址连接。 ## MySQL端口可不可以从3306改成别的，能防扫描吗？ 可以改。在my.cnf的[mysqld]段加port = 13306，重启即可。改端口对自动化扫描器有一定效果（蠕虫脚本通常只扫3306），但不能依赖。专业的攻击者用nmap全端口扫描几分钟就能发现，所谓"通过改端口提高安全性"叫security through obscurity，安全圈普遍认为不算真正的安全措施。改端口的真正用途是减少日志噪音和被随手扫描骚扰，真正的安全还得靠强密码、白名单、SSL、SSH隧道这几层。 ## 写在最后 MySQL远程连接这件事，单独看每一步都不复杂，但完整跑通需要同时搞定配置文件、用户权限、防火墙、云安全组四个环节，任何一处漏了都会卡住。保哥的经验是按本文的顺序逐项checklist走一遍，9成的问题都能在十几分钟内定位。剩下的那1成多半是云厂商奇葩限制（SELinux (https://zhangwenbao.com/linux-selinux-modes-contexts-booleans-troubleshooting-audit2allow.html)或AppArmor在拦、RDS Parameter Group强制SSL）或者奇葩的客户端driver兼容问题——那就是另一篇文章的故事了。 真正稳定的生产环境配置，保哥的推荐顺序是：MySQL bind内网IP + 业务账号细粒度授权 + 跳板机SSH隧道访问 + 全程SSL加密 + 审计日志开启。每一层都做完，远程访问MySQL既灵活又安全。任何一层偷懒，都可能成为下一次安全事件的入口。 ## 权威参考资料 ## phpMyAdmin导大SQL失败：3种解法实战 - URL：https://zhangwenbao.com/phpmyadmin-import-large-sql-files.html - 分类：MySQL - 发布：2017-01-18 | 更新：2026-06-02 - 摘要：phpMyAdmin导入大SQL文件总是超时超限。本文给出三种解法：从upload_max_filesize、post_max_size、Nginx body大小等五个参数联动调起，到用服务器端导入目录绕过浏览器上传，再到mysql命令行配进度显示与多线程并行，附常见报错处置和迁移规划。 - 关键词：PHP.ini,MySQL导入,PHPMyAdmin,MyQL导入,file_uploads > **TLDR**：摘要：phpMyAdmin导入大SQL文件总是超时超限，根子在PHP上传配置和脚本执行时间卡着脖子。本文按操作顺序给三种解法——先改php.ini放宽upload_max_filesize与post_max_size、再启用phpMyAdmin服务器端导入目录绕过浏览器上传、最后用命令行配mydumper大力出奇迹，并附导入失败的错误排查清单、过程中该看哪些指标和迁移规划。 > 摘要：phpMyAdmin导入大SQL文件总是超时超限，根子在PHP上传配置和脚本执行时间卡着脖子。本文按操作顺序给三种解法——先改php.ini放宽upload_max_filesize与post_max_size、再启用phpMyAdmin服务器端导入目录绕过浏览器上传、最后用命令行配mydumper大力出奇迹，并附导入失败的错误排查清单、过程中该看哪些指标和迁移规划。 保哥从 2010 年前后开始用 phpMyAdmin 管理 MySQL 数据库，那个时候做企业站、做博客搬家，数据库文件动不动就好几百兆甚至上 G，导入失败几乎是家常便饭。第一次遇到的时候，保哥以为是导出的 SQL 文件本身坏了，反复重导、反复报错，浪费了整整一个下午才意识到根本不是文件的问题，而是 PHP 上传配置和脚本执行时间在背后卡着脖子。这些年下来，保哥陆陆续续帮自己也帮朋友处理过几十次类似的大数据库导入需求，从最早期的虚拟主机时代到现在的云服务器时代，方法已经迭代了好几轮。本文按操作顺序整理出可直接抄走的实战手册：放宽 PHP 限制、启用服务器端导入目录、命令行/mydumper 终极解法，以及完整的错误排查清单。 ## 为什么 phpMyAdmin 导入大 SQL 文件总是失败 先说结论：phpMyAdmin 是一个跑在 PHP 之上的 Web 管理工具，所以它能处理多大的文件，本质上由 PHP 的几个上传与执行参数共同决定。当你点击界面上的"导入"按钮，浏览器会把 .sql 文件通过 HTTP 表单 POST 到服务器，PHP 接收完毕后再交给 phpMyAdmin 解析、逐条执行 SQL 语句。这条链路上有四个最容易踩到的硬性限制，几乎每一个排查大文件导入失败的工程师都绕不开它们。 第一个是 upload_max_filesize，这是 PHP 允许通过 HTTP 上传的单文件最大体积，默认值只有 2MB，稍微大一点的备份就会直接被 PHP 在接收阶段拒绝。第二个是 post_max_size，整个 POST 请求体的上限，包括所有表单字段加文件，一般要比 upload_max_filesize 设置得稍大一点，否则同样会被拦下来。第三个是 max_execution_time，PHP 脚本最长执行时间，默认 30 秒，对于上万行 SQL 来说远远不够用，你看到的"白屏"或者"504 网关超时"基本都和它有关。第四个是 memory_limit，PHP 单个请求的内存上限，phpMyAdmin 解析大文件时如果一次性读太多就会触发内存溢出。 保哥早期吃过最大的亏，是只改了 upload_max_filesize，没动 post_max_size，结果 phpMyAdmin 一直报"文件太大"，一度怀疑是配置没生效，重启了好几次 PHP 才发现这两个参数必须联动调整。还有一次更离奇，参数都改对了文件能上传成功，但导入到一半浏览器就显示连接被重置，最后定位到原因是 Nginx 的 client_max_body_size 默认只有 1MB，请求在 Nginx 层就被切掉了，根本没到 PHP。所以这条链路涉及的不止是 PHP 一家，Web 服务器、PHP、MySQL 三方都要配合。下一节先把 PHP 这一层调好。 ## 修改 php.ini 放宽上传与执行限制 在动手改 php.ini 之前，保哥强烈建议先用一个小脚本确认你当前实际生效的配置文件路径，避免改错地方。新建一个 phpinfo.php 放到网站根目录： **TLDR**：摘要：MySQL报server has gone away，根因其实分好几种。本文按占比拆五类场景——max_allowed_packet包超限最常见、wait_timeout会话被踢、读写超时、mysqld进程崩溃、中间链路RST断连，每种给判别方法和参数，再讲8.0与5.7的默认值差异、导入8GB数据库和phpMyAdmin总断开两个实战复盘，以及导大文件前的检查清单。 > 摘要：MySQL报server has gone away，根因其实分好几种。本文按占比拆五类场景——max_allowed_packet包超限最常见、wait_timeout会话被踢、读写超时、mysqld进程崩溃、中间链路RST断连，每种给判别方法和参数，再讲8.0与5.7的默认值差异、导入8GB数据库和phpMyAdmin (https://zhangwenbao.com/phpmyadmin-import-large-sql-files.html)总断开两个实战复盘，以及导大文件前的检查清单。 "ERROR 2006 (HY000) at line 1234: MySQL server has gone away" 这条报错每次出现都让人怀疑人生。打开 SQL 文件确认行数没问题，重启 MySQL 服务再试还是同样位置失败，搜了一圈别人都告诉你改 max_allowed_packet，改完依然失败。这是因为 server has gone away 这个错误根本不是只对应一个原因——保哥这几年帮 30 多个客户处理过类似问题，至少能列出五个完全不同的根因，每个根因对应的修复路径都不同。本文把这些根因和对应的解决路径系统整理出来，并给出每一种情况下怎么快速定位到属于哪一种。 前置说明：本文实测环境是 MySQL 5.7.37 / 8.0.34 双版本对照，操作系统覆盖 Windows Server 2019 + IIS、CentOS 7.9 + Nginx、Ubuntu 22.04 + Docker (https://zhangwenbao.com/wordpress-docker-containerized-deployment-environment-consistency.html) 三种生产部署。报错出现在 phpMyAdmin / Navicat / 命令行 mysql 客户端 / MySQL Workbench 四种工具里行为略有差异，本文会标明哪种工具最容易在哪种根因下复现。 ## 报错的本质：客户端发现 TCP 连接已断 很多教程一上来就让你改 max_allowed_packet，这是把表象当了根因。"server has gone away" 的字面意思是"服务器已离开"，技术上是客户端在某次发送 SQL 后等待响应，但 TCP 连接已经被对端关闭——客户端发现连接断了所以抛出这个错。 连接为什么会断？至少有以下几种独立场景： - 客户端单条 SQL 太大，超过了服务器允许接收的最大包大小（max_allowed_packet）。服务器选择关闭连接。 - 客户端空闲时间过长，超过了服务器的会话超时（wait_timeout / interactive_timeout）。服务器主动断开。 - 客户端发送数据过慢或读取响应过慢，超过了 net_read_timeout / net_write_timeout。服务器主动断开。 - MySQL 服务器在执行过程中崩溃或被系统 kill（OOM、磁盘满、replication 错误等）。整个 mysqld 进程消失。 - 中间链路设备（NAT 网关、防火墙、负载均衡）超时断了连接，MySQL 服务器和客户端都不知情。 不同场景的处理方式完全不同。盲目改 max_allowed_packet 在后面四种情况下毫无效果——很多人改了无数次配置没用，就是因为根本不是包大小的问题。 ## 包大小超限：max_allowed_packet 不足（最常见，约占 60%） 典型症状：导入 SQL 文件中途报错，错误信息里会附带行号。把报错行附近的 INSERT 语句单独拿出来看，通常是某条 INSERT 包含特别大的 BLOB / TEXT 字段，或者一次性 INSERT 几千行 VALUES。 查看当前值： SHOW VARIABLES LIKE 'max_allowed_packet'; MySQL 5.7 默认是 4MB，MySQL 8.0 默认是 64MB。如果你的 SQL 文件里有 BLOB 字段（比如存图片二进制、长 JSON 配置、压缩后的日志归档），4MB 几乎一定会触发。 修复方法分两步——先在运行时临时调，再写进配置文件持久化。 运行时临时调（不需要重启 MySQL，但只对新建立的连接生效）： SET GLOBAL max_allowed_packet = 256 * 1024 * 1024; 写入配置文件持久化。Windows 路径通常是 C:\ProgramData\MySQL\MySQL Server 8.0\my.ini（注意 ProgramData 是隐藏目录，资源管理器要打开"显示隐藏文件"才能看到）。Linux 路径通常是 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf。在 [mysqld] 段添加： [mysqld] max_allowed_packet = 256M 注意 [mysqld] 不要写错成 [mysql]——[mysql] 段只影响命令行客户端，对服务器无效。改完保存，重启 MySQL 服务才生效。Windows 用 services.msc 找 MySQL80 服务点重启；Linux 用 systemctl restart mysqld。 保哥经验值：生产环境推荐 256M 起步。如果你确实需要导入更大的单条数据（视频、大型 PDF），可以加到 1G，但要同步加大 innodb_log_file_size——否则会触发别的崩溃。max_allowed_packet 没有硬性上限，但实际工程经验上 1GB 是个分水岭，更大的值很少有实际需求。 ## 会话被踢：wait_timeout 过短（约占 15%） 典型症状：导入小到中等大小 SQL 文件，前面几千行都顺利，但中间某段执行得慢的复杂存储过程或者大事务卡住，几分钟后报 server has gone away。其实数据库还活着，是会话被超时机制踢出去了。 查看当前值： SHOW VARIABLES LIKE 'wait_timeout'; SHOW VARIABLES LIKE 'interactive_timeout'; 这两个参数都默认 28800 秒（8 小时），听起来很长，但宝塔面板 (https://zhangwenbao.com/bt-panel-automatic-disk-mount.html)、cPanel、各类托管 MySQL 服务为了"防止僵尸连接"经常把这两个值改到 60 秒甚至 30 秒。保哥见过一个共享主机环境 wait_timeout 设到 10 秒——这种场景下任何稍微慢一点的 SQL 都会被踢。 修复：在 [mysqld] 段设置 [mysqld] wait_timeout = 28800 interactive_timeout = 28800 注意 interactive_timeout 影响交互式客户端（比如命令行 mysql、Navicat、Workbench），wait_timeout 影响应用程序连接（PHP 的 mysqli、Python 的 pymysql 等）。两个都要改。改完重启服务。 更细的细节是这两个参数都有 session 级别和 global 级别。SET SESSION wait_timeout 只影响当前会话；SET GLOBAL wait_timeout 影响后续所有新会话但不影响已经建立的会话。导入 SQL 之前先 SET SESSION 一下是临时方案，长期方案必须改配置文件。 ## 网络收发超时：net_read_timeout / net_write_timeout 过短（约占 10%） 典型症状：phpMyAdmin 在浏览器上导入 SQL 文件，浏览器自身在传输大文件，PHP 也在分块解析转发给 MySQL，整个链路慢，MySQL 在等待客户端继续发送下一段数据时超时了。常见于上传几百 MB 以上 SQL 文件经过 phpMyAdmin 的场景。 查看当前值： SHOW VARIABLES LIKE 'net_read_timeout'; SHOW VARIABLES LIKE 'net_write_timeout'; 默认 30 秒和 60 秒。客户端如果在 30 秒内没把下一个数据包发到，MySQL 会主动断连。慢链路、phpMyAdmin 分块上传、网络抖动都可能踩到。 修复： [mysqld] net_read_timeout = 600 net_write_timeout = 600 提到 600 秒（10 分钟）通常足够覆盖中等规模导入的网络波动。生产环境不建议设到过大，因为这两个参数过大会让僵尸连接难以清理。 ## MySQL 服务进程崩溃（约占 8%） 典型症状：导入过程中突然报错，MySQL 服务直接停止，client 看到 server has gone away。再去后台看 MySQL 服务状态发现是 Stopped。这种情况不是配置问题，是 mysqld 进程崩溃了。 排查路径： - 看 MySQL 错误日志。Windows 在 C:\ProgramData\MySQL\MySQL Server 8.0\Data\.err，Linux 通常在 /var/log/mysqld.log 或 /var/lib/mysql/.err。错误日志里会有崩溃栈或者关键报错。 - 查系统日志。Windows 在事件查看器 - 应用程序，找 MySQL 相关错误。Linux 用 dmesg | grep -i 'killed process' 查看是否触发 OOM killer。 - 看磁盘空间。MySQL 数据目录和 InnoDB 日志目录是否写满。df -h 一目了然。 常见崩溃原因： - 内存不足触发 OOM killer：MySQL 申请内存超过系统可用，Linux 内核杀了 mysqld。处理：降低 innodb_buffer_pool_size，或加内存，或开启 swap。 - 磁盘写满：数据目录所在分区满了，新写入失败。处理：清理或扩盘。 - InnoDB redo log 文件损坏：极少见但出现过。处理：先备份数据目录，按官方文档做 forced recovery 启动。 - SELECT INTO OUTFILE 写入路径权限不足：Linux 下 mysql 用户没有目标目录写权限会让 mysqld 崩。处理：把目标路径改到 /tmp 或 chown 给 mysql 用户。 ## 中间链路 RST 断连（约占 7%） 典型症状：远程连接 MySQL（比如 Navicat 跨网段连接生产库），刚连上一切正常，闲置一段时间后任意操作就报 server has gone away。MySQL 服务器没崩溃，配置也没问题——是中间的 NAT 网关、防火墙、负载均衡器把"长时间无数据传输"的 TCP 连接当成失效的清掉了。 这一类问题特别容易被误诊为 MySQL 本身的问题。排查路径： - 在客户端开两个会话，一个执行 SELECT 后立即看另一个会话的 SHOW PROCESSLIST。如果第二个会话能看到第一个会话还在，说明断的是中间链路不是 MySQL。 - 用 tcpdump 或 Wireshark 抓包。如果 MySQL 服务器和客户端之间出现 RST 包（来自第三方 IP），就是中间设备主动断的。 修复方向： - 客户端开启 TCP keepalive。Linux 用 SO_KEEPALIVE 套接字选项。MySQL 5.7.9 后 mysqld 自身有 net_buffer_length 和 connection_control 插件能帮忙。 - 中间设备调长会话超时。云厂商的 NAT 网关、SLB 通常默认 5 分钟无流量断连，可以调到 60 分钟。 - 应用层心跳。每隔 30 秒发一个 SELECT 1 让 TCP 连接保持活跃。连接池（HikariCP、Druid）通常都有这个机制。 ## 怎么快速判断你属于哪一种根因 遇到 server has gone away 时，按这个顺序快速定位： - 看报错出现的位置。如果总在 SQL 文件的同一行（同一条 INSERT）报错——属于包大小超限场景（max_allowed_packet）。如果在不同行随机报错——继续看下面。 - 看 MySQL 服务是否还在运行。Windows 看 services.msc 里 MySQL 服务状态，Linux 用 systemctl status mysqld。如果服务停止——属于服务进程崩溃场景，去看错误日志。 - 看导入耗时。如果是导入到固定时间（比如 60 秒、5 分钟）后就断——属于超时场景（会话被踢或网络收发超时）。看 wait_timeout 和 net_read_timeout 的具体值。 - 看客户端到服务器的网络路径。如果客户端和 MySQL 服务器之间隔了 NAT、防火墙、负载均衡——属于中间链路 RST 断连场景，先排除链路设备超时。 保哥的实战经验：80% 以上的情况通过前两步就能定位。剩下 20% 多半是组合问题——比如同时存在 max_allowed_packet 不够和 wait_timeout 过短，改一个不够还要再排查另一个。 ## 实战案例：导入 8GB 客户数据库到本地 2026 年 3 月帮一个 ECShop 客户做整站迁移，要把 8GB 的 SQL 文件（含 12 万订单、47 万商品图片 BLOB）导入到开发环境。第一次直接用 mysql 命令行导入，跑到约 1.2GB 位置（大概是某个 BLOB 字段超大的订单导入时）报 server has gone away。 排查过程： - 看错误位置，是同一行报错——属于包大小超限场景。 - 查 max_allowed_packet，默认 4MB——确诊。 - SHOW VARIABLES LIKE 'innodb_log_file_size'，48MB——也偏小，预计后面也会出问题。 修复方案（一次性把相关参数都调好，避免反复 debug）： [mysqld] max_allowed_packet = 1G innodb_log_file_size = 512M innodb_log_buffer_size = 64M wait_timeout = 28800 interactive_timeout = 28800 net_read_timeout = 600 net_write_timeout = 600 innodb_buffer_pool_size = 4G 注意 innodb_log_file_size 调大不能直接重启——会因为现存日志文件和配置不一致而启动失败。正确步骤是： - SET GLOBAL innodb_fast_shutdown = 0; （让 MySQL 干净关闭，flush 所有 dirty page） - 停止 MySQL 服务 - 移走旧的 ib_logfile0 / ib_logfile1（备份不删） - 启动 MySQL，会自动按新配置生成新日志文件 调好后重新导入，全程顺利，耗时 47 分钟。同一台机器、同样的 SQL 文件，参数不对就一直失败，参数对了就一气呵成——这就是为什么不能盲目改一个参数后死循环重试。 ## 实战案例：phpMyAdmin 总是中途断开 另一个客户的场景：宝塔面板 + phpMyAdmin，导入 1.2GB 的 SQL 文件，每次都在 5 分钟左右断。改 max_allowed_packet 没用，因为他的单条 SQL 都不大；改 wait_timeout 也没用。 这种场景实际上是 PHP 自身的 max_execution_time / upload_max_filesize 触顶。phpMyAdmin 的导入过程是浏览器先上传到 PHP，PHP 解析后再分块发给 MySQL。PHP 自己超时了，整个链路就断，MySQL 客户端那侧表现为 server has gone away。 修复要同时改 PHP 配置： upload_max_filesize = 2000M post_max_size = 2000M memory_limit = 2000M max_execution_time = 3600 max_input_time = 3600 改完重启 PHP-FPM 服务。这才是 phpMyAdmin 场景下中断的真凶——和 MySQL 本身的配置没关系。 ## MySQL 8.0 与 5.7 的默认值差异 下面是和"server has gone away"相关的参数在 5.7 和 8.0 默认值对比表，帮你判断升级 MySQL 后哪些参数需要重新调： 参数 | MySQL 5.7 默认 | MySQL 8.0 默认 | 影响 | max_allowed_packet | 4MB | 64MB | 8.0 默认更宽松 | wait_timeout | 28800 秒 | 28800 秒 | 相同 | interactive_timeout | 28800 秒 | 28800 秒 | 相同 | net_read_timeout | 30 秒 | 30 秒 | 相同 | net_write_timeout | 60 秒 | 60 秒 | 相同 | innodb_log_file_size | 48MB | 48MB | 相同 | innodb_buffer_pool_size | 128MB | 128MB | 相同，但 8.0 chunk 机制不同 | 从 5.7 升级到 8.0 后，最值得关注的是 max_allowed_packet 默认从 4MB 提到了 64MB——很多以前会触发 server has gone away 的场景在 8.0 上不再出现。但 wait_timeout / net_read_timeout 都没变，对应的报错依然存在。 ## 容易被忽视的几个细节 - my.cnf 修改不生效：Linux 上有时改了 /etc/my.cnf 但 MySQL 启动时实际读的是 /etc/mysql/my.cnf 或者 /etc/mysql/mariadb.conf.d/50-server.cnf。用 mysqld --verbose --help | grep -A 1 'Default options' 能看到 MySQL 实际读取的配置文件搜索顺序。 - Windows my.ini 编码必须 ANSI：用记事本编辑 my.ini 时不要保存为 UTF-8，否则 MySQL 启动会报参数解析错误。VS Code 或 Notepad++ (https://zhangwenbao.com/use-notepad-to-batch-delete-blank-lines-in-the-code.html) 编辑时保存为 ANSI/GBK。 - SHOW VARIABLES 看到的是当前 session 的值：很多人在 Navicat 里 SET GLOBAL 之后 SHOW VARIABLES 还是看到旧值，以为没生效——SHOW VARIABLES 默认是 session 范围，你需要 SHOW GLOBAL VARIABLES 才能看 global 范围。 - 容器化部署的 MySQL：Docker 启动 MySQL 容器时通过 -e MYSQL_ROOT_PASSWORD 这种环境变量配置，max_allowed_packet 要在 docker run 时通过 --max-allowed-packet=256M 或者挂载自定义 my.cnf 设置。 - 使用云数据库时配置参数被限制：阿里云 RDS、AWS RDS 的部分参数只能通过控制台的参数组修改，不能通过 SET GLOBAL 改。 ## 预防策略：导入大文件之前的检查清单 下次再要导入大 SQL 文件，按这个清单走能避免大部分坑： - SHOW VARIABLES LIKE 'max_allowed_packet'；如果小于 256M 先调大。 - SHOW VARIABLES LIKE 'wait_timeout'；如果小于 1800 先调大。 - SHOW VARIABLES LIKE 'net_read_timeout'；如果小于 300 先调大。 - df -h 看一下数据目录所在分区空间，至少要有 SQL 文件 2 倍的剩余空间（导入过程中需要写 redo log）。 - free -h 看一下内存，innodb_buffer_pool_size 不要超过物理内存 70%。 - 用 split 命令把超大 SQL 文件拆成 100MB 一段：split -b 100M dump.sql dump_part_，然后逐段导入。这样即使某段失败也能快速定位。 ## 常见问题解答 ## SET GLOBAL max_allowed_packet 设置后为什么 SHOW VARIABLES 还是旧值 SHOW VARIABLES 默认查 session 级别的变量，SET GLOBAL 只改 global 级别但不影响已经存在的 session。需要在新建立的连接里 SHOW VARIABLES 才能看到新值，或者用 SHOW GLOBAL VARIABLES LIKE 'max_allowed_packet' 直接查 global 值。永久生效必须写进 my.cnf / my.ini 并重启 MySQL 服务。 ## 为什么改了 my.cnf 重启后参数没生效 最常见的原因是改的不是 MySQL 实际加载的配置文件。Linux 系统可以用 mysqld --verbose --help | grep -A 1 'Default options' 看 MySQL 启动时读取配置文件的搜索顺序，通常会列出 /etc/my.cnf、/etc/mysql/my.cnf、~/.my.cnf 等。MySQL 按顺序读取，后读的会覆盖先读的。第二个常见原因是 [mysqld] 段写错成了 [mysql] 或者 [client]，只有 [mysqld] 段下的配置才会被服务进程读取。 ## max_allowed_packet 设到多大才合适 没有标准答案。保哥的经验值：开发环境 256MB 起步覆盖绝大多数场景；生产环境如果只跑业务 SQL，256MB 也足够；如果要支持单条 SQL 包含大 BLOB（视频、PDF、压缩归档），可以设到 1G。MySQL 官方手册的硬上限是 1GB，但实际部署到接近 1GB 容易触发别的连锁问题（比如 innodb_log_file_size、innodb_buffer_pool_size 都要相应调整）。盲目设到最大不是好做法，按实际数据特征评估。 ## mysqldump 备份时也报 server has gone away 怎么办 mysqldump 默认会 SELECT 整张表，对大表来说一次性传输几个 GB 数据，过程中受 max_allowed_packet 和 net_write_timeout 双重制约。解决：mysqldump 加 --max_allowed_packet=1G 参数；同时把 --net-write-timeout 也调大；对超大表可以加 --single-transaction --quick 让 mysqldump 流式输出而不是缓存到内存再写。最后的兜底是 mysqldump 分库分表导出，按时间或 ID 范围切片。 ## 云数据库（RDS）的 max_allowed_packet 怎么改 阿里云 RDS、腾讯云 CDB、AWS RDS 的 max_allowed_packet 都是通过控制台的"参数组"或"参数模板"修改，不能通过 SET GLOBAL 直接改。具体操作：进入 RDS 实例控制台 → 参数配置 → 找到 max_allowed_packet → 修改新值 → 提交参数变更。修改后部分参数立即生效，部分需要重启实例。修改之前一定要看清楚是不是"重启生效"类参数，避免影响线上业务。 ## Navicat 远程连接 MySQL 反复断开是 server has gone away 吗 表象类似但根因通常是中间链路超时。Navicat 远程连接经常隔着 NAT 网关、防火墙、跳板机，这些中间设备的会话超时（通常 5 到 15 分钟无流量就断）比 MySQL 自身的 wait_timeout（默认 8 小时）严格得多。解决：在 Navicat 的连接设置 → 高级 → 勾选'保持连接间隔'，设到 30 秒。这会让 Navicat 每 30 秒发一个心跳保持 TCP 连接活跃。MySQL 服务器侧不需要任何修改。 ## 升 8.0 之后还会遇到 server has gone away 吗 会，但概率明显降低。MySQL 8.0 默认 max_allowed_packet 从 4MB 提到 64MB，覆盖了一大批默认会触发的场景。但 wait_timeout、net_read_timeout 这些参数 8.0 没有改动，对应根因下的报错依然存在。升级 MySQL 不是一劳永逸的解决方案，正确的做法是根据自己的负载特征调参。 ## 有没有办法在客户端层面避免这个错误 有几种客户端层面的兜底。第一是开启自动重连——PHP 的 mysqli 有 mysqli_options 设置 MYSQLI_OPT_RECONNECT，Python pymysql 有 ping(reconnect=True)，Java JDBC URL 加 autoReconnect=true。但自动重连不能修复事务中断——重连后事务状态丢失，未提交的数据会丢。第二是连接池配置合理的 testQuery 和 testWhileIdle。第三是在长事务前显式 ping 一下确认连接还活着。客户端兜底只能减少影响，不能根治问题，根因还在服务端。 ## 权威参考资料