source命令本质是逐行发送SQL语句，非单事务执行；真正卡死主因是默认无提交的长事务导致InnoDB内存溢出，而非网络或磁盘性能问题。
source命令本质是单事务执行，不是“慢”，是内存爆了
MySQL 的 source 命令本身不卡，它只是把文件内容逐行读入客户端、再发给服务端执行。真正卡死的根源是：默认情况下，整个 SQL 文件被当做一个超长事务来处理。尤其是含 CREATE TABLE + 百万级 INSERT 的备份文件，InnoDB 的 undo log 和 buffer pool 会持续膨胀，直到触发 OOM 或被系统 kill。这不是网络延迟或磁盘慢，而是服务端内存扛不住了。
- 现象典型：导入到 60%–80% 时突然卡住，
top显示 mysqld 进程 RSS 内存飙升至 10GB+，CPU 占用却不高 - 关键证据：查看
SHOW ENGINE INNODB STATUS\G中的LOG段，能看到log sequence number增长极快，log buffer几乎满载 - 别信“加大 max_allowed_packet 就能解决”——这个参数只影响单条语句长度，对事务累积压力无效
文件里藏着“隐形大事务”，你根本没意识到
很多人以为自己导的是“一堆 INSERT”，但实际导出工具（如 mysqldump）默认会在每个表的 INSERT 块前加 LOCK TABLES 和 DISABLE KEYS，结尾才 ENABLE KEYS。这些语句本身不提交，但会让 InnoDB 持有锁和缓存结构，进一步拖慢进度。更隐蔽的是：如果 dump 时用了 --skip-extended-insert，每行一个 INSERT，那等于生成了上百万个独立语句——客户端解析开销 + 网络往返 + 服务端日志刷盘，全叠加在无提交点的长事务上。
- 检查方法：用
head -20 big.sql | grep -E "(BEGIN|COMMIT|LOCK|DISABLE)"看有没有隐式事务控制 - 危险信号：文件开头没有
SET autocommit=0;，结尾没有COMMIT;，且中间无任何COMMIT或;分隔的批量块 - 修复方向不是“改 source”，而是提前拆分——用
sed -n '/INSERT INTO.*VALUES/,/;/p' file.sql | split -l 5000切成带完整语句块的小文件
MySQL 客户端连接配置不当，让卡死提前发生
即使服务端还能撑，客户端也可能先断。比如默认的 wait_timeout=28800（8 小时），看似够用，但若导入中途因磁盘 I/O 阻塞、buffer pool flush 暂停超过 60 秒，客户端收不到响应，就会主动关闭连接，报错 Lost connection to MySQL server during query。这不是服务端挂了，是客户端等不及了。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 必须同步调客户端和服务端：登录后立刻执行
SET SESSION wait_timeout = 86400;，同时确认服务端max_execution_time未设限 -
mysql --defaults-file比命令行传参更可靠，避免 shell 解析空格或特殊字符导致连接失败 - 禁用
mysql -u root -p 这种重定向方式——它绕过客户端命令解析逻辑，无法插入 <code>SET控制语句，也丢失错误定位能力
真正有效的做法不是“优化 source”，是绕过它
面对 GB 级备份文件，source 是最不推荐的路径。它的设计目标是调试和小脚本，不是生产级数据迁移。你花两小时调参数，不如花十分钟把文件转成更适合批量加载的格式。
- 纯数据场景：用
mysqlimport替代，前提是已有对应表结构，且数据是 tab 分隔的纯文本（比 INSERT 快 5–10 倍） - 混合结构+数据：用
mysqldump --tab导出，得到.sql（建表）+.txt（数据），再分别用source和mysqlimport加载 - 必须用 SQL 文件时：用 Python 脚本扫描
INSERT语句，每 5000 行包一层BEGIN; ... COMMIT;，并删掉所有LOCK TABLES和DISABLE KEYS
卡死的本质从来不是“文件太大”，而是你让一个面向交互的工具去干批处理的活。最容易被忽略的一点：很多团队在 CI 流水线里还用 source 执行初始化脚本，只要某次 build 机器内存稍小，就必然失败——这种稳定性陷阱，比性能问题更致命。
