必须同时调服务端、客户端命令行和会话级max_allowed_packet，三者不一致会导致导入失败；还需同步调整net_read_timeout、net_write_timeout、wait_timeout、interactive_timeout等超时参数，并注意innodb_log_file_size和innodb_buffer_pool_size对稳定性的间接影响。
能，但必须同时调服务端参数、客户端命令和导入方式，单改某一项大概率失败。
哪些MySQL参数必须调？
导入中断或锁死，90%以上是这几个参数没对齐：
-
max_allowed_packet：决定单条语句最大能多大。默认 4MB 或 64MB，遇到带长文本/二进制字段的 INSERT 就直接报Packets larger than max_allowed_packet are not allowed。建议设为1073741824（1GB）或更高，但别超过 2GB，否则 MySQL 启动可能失败。 -
net_read_timeout和net_write_timeout：控制服务端读/写数据时的等待上限。默认 30 秒，大文件导入中间空闲几秒就断连。设为600（10 分钟）较稳妥。 -
wait_timeout和interactive_timeout：前者管非交互连接（如脚本导入），后者管 mysql 命令行这类交互式连接。两者都得调，比如设成28800（8 小时），避免连接被服务端主动踢掉。 -
innodb_log_file_size和innodb_buffer_pool_size：不是超时参数，但影响稳定性。log 文件太小会导致频繁刷盘卡住；buffer pool 太小会让大量 INSERT 反复换页，拖慢甚至 OOM。前者建议 ≥512M，后者建议设为物理内存的 50–70%。
mysql 命令行导入怎么防断连？
光改配置文件不够，命令本身也得加防护。用 mysql 客户端导入时，必须显式传参，否则它会按默认值建连接，跟你在 my.cnf 里写的无关：
- 用
--max_allowed_packet=1G覆盖客户端包大小限制，和服务端保持一致； - 加
--connect-timeout=0禁用初始连接超时（仅限导入场景，生产慎用）； - 用
--init-command在连接建立后立刻执行 SET，例如：--init-command="SET SESSION net_read_timeout=600, SESSION net_write_timeout=600"； - 绝对不要用
source命令在交互式 mysql shell 里导入大文件——它不支持超时控制，且无法捕获中间错误位置。
为什么拆分 SQL 文件有时比调参更有效？
因为很多“锁死”根本不是超时，而是某一条语句触发了内存峰值或锁竞争。比如一个含 10 万行 VALUES 的 INSERT，MySQL 要一次性解析、校验、分配内存，极易崩。拆分后：
- 每段控制在 10–50MB，对应约 10 万–50 万行 INSERT；
- 用
split -b 20M dump.sql part_快速切分，再逐个导入； - 拆完可加事务包裹：每个文件开头加
START TRANSACTION;，结尾加COMMIT;，避免中途失败污染状态； - 如果原文件含
CREATE TABLE或DROP TABLE，拆分前先用 sed 抽出 DDL 单独执行，后续只导 DATA，减少语句类型混杂带来的不确定性。
容易被忽略的关键点
真正卡住你的，往往不是参数数字本身，而是它们之间的配合关系：
-
max_allowed_packet必须在客户端命令、服务端配置、以及 session 级 SET 中三处一致，漏一处就可能失败； - 修改
my.cnf后必须重启 MySQL，SET GLOBAL只对新连接生效，已存在的连接不受影响； - 阿里云 RDS、腾讯云 CDB 等托管服务不支持修改所有参数，
max_allowed_packet和wait_timeout通常可调，但innodb_log_file_size不可改，得换用其他策略； - 导入前务必确认文件编码是 UTF8MB4，否则
SET NAMES utf8mb4不生效，中文字段乱码可能间接导致语法错误中断。
