MySQL主动断连主因是max_allowed_packet过小或wait_timeout超时，需同步调大服务端与客户端max_allowed_packet、合理设置wait_timeout/interactive_timeout，并检查PHP upload_max_filesize和post_max_size匹配性，同时排除SQL文件BOM头或截断问题。
max_allowed_packet太小导致MySQL主动断连
这不是网络抖动或PHP超时，而是MySQL服务端收到单条语句（比如含上万行VALUES的INSERT）超过max_allowed_packet限制后，直接丢包并关闭连接。错误日志里通常带ER_NET_PACKET_TOO_LARGE或Got a packet bigger than 'max_allowed_packet' bytes。
关键点在于：这个值控制的是“单个网络包”大小，和SQL文件总大小无关，而和最长那条语句的字节数强相关。例如一个含Base64图片的INSERT INTO ... VALUES (...)可能单行就占8MB。
- 必须同时检查
SELECT @@global.max_allowed_packet和SELECT @@session.max_allowed_packet——后者才是phpMyAdmin当前连接实际生效的值 - RDS默认仅4MB，建议设为
268435456（256MB），改完需重启实例才生效 - phpMyAdmin自身不设客户端级
max_allowed_packet，它完全依赖MySQL服务端配置
wait_timeout过短让连接被服务端“踢出”
phpMyAdmin导入是HTTP请求，执行SQL期间没有心跳保活。如果导入耗时超过MySQL的wait_timeout（默认通常8小时，但某些托管环境会调低到60秒），服务端就会主动断开空闲连接，报错MySQL server has gone away。
注意：interactive_timeout也得一并确认，两者都影响phpMyAdmin这类非交互式连接的行为。
- 在RDS控制台「参数设置」中搜索
wait_timeout，建议设为28800（8小时） - 执行
SHOW VARIABLES LIKE '%timeout%';确认两个值是否已同步生效 - 别只改
my.cnf就以为完事——RDS必须在控制台修改并重启实例
PHP层upload_max_filesize和post_max_size不匹配
文件根本没传全，就被PHP截断了。常见现象是页面空白、进度条卡住、或只导入前几KB。这不是MySQL的问题，而是PHP在接收阶段就失败了。
-
post_max_size必须≥upload_max_filesize，建议设为后者+10%，例如upload_max_filesize = 512M→post_max_size = 560M - 改完php.ini后，必须重启Web服务器（Apache/Nginx）和PHP-FPM，仅reload无效
- 用
phpinfo()页面确认实际生效值，别信配置文件里的注释
SQL文件含BOM头或被意外截断
开头三个字节EF BB BF（UTF-8 BOM）会让MySQL客户端解析首行失败，后续语句错位，某条INSERT可能被拼成超长语句；文件末尾被截断则导致MySQL收到半条语句，直接reset连接——这两类问题常被误报为SSL错误或连接重置。
- 用
hexdump -C your_file.sql | head -n 1检查开头是否为ef bb bf，是则用VS Code保存为“UTF-8 无BOM” - 用
tail -c 20 your_file.sql | hexdump -C看结尾是否突兀中断（比如最后是INS而非完整INSERT） - 别轻信错误信息里写的“SSL”，先排除BOM和截断，再查
max_allowed_packet
真正麻烦的是：这些限制层层嵌套，改一个参数往往不够。比如调高了max_allowed_packet，但wait_timeout仍很短，或者PHP的post_max_size没同步，照样断。大文件导入最稳的方式，还是绕过phpMyAdmin，用mysql命令行直导。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
