直接切分 mysqldump 生成的 SQL 文件风险极高，因 split -l 按行切会破坏 INSERT 或 CREATE TABLE 等跨行语句完整性，导致导入报错；必须按语句边界切分，推荐用 Python 状态机解析或导出时控制文件大小。
直接切分 mysqldump 生成的 SQL 文件风险极高，split -l 按行切会把一条 INSERT 或 CREATE TABLE 语句硬生生劈开，导入时必然报错。
为什么 split -l 不适合切 MySQL SQL 文件
MySQL 的 SQL 导出文件不是纯文本日志，而是由完整语句构成的逻辑单元。常见问题包括：
-
INSERT INTO ... VALUES (...), (...), (...);这种多值插入可能跨多行，split -l 1000很可能在括号中间断开 -
CREATE TABLE后紧跟几十行字段定义和索引，切在ENGINE=InnoDB;前面会导致语法错误 - 注释（
--或/* */）和空行干扰行计数，实际语句边界远比行号复杂
真正可用的切分方式：按语句边界拆分
必须识别 ; 是否处于字符串、注释或括号内——这超出了 split 能力范围。推荐两种实操路径：
- 用
sed -n '/^--/!{/;/p;}' full_dump.sql | split -l 500 - part_：先过滤掉注释行，再提取含分号的行，最后按行切。适用于结构简单、无嵌套引号的 dump，但无法处理INSERT中带分号的字符串值 - 用 Python 写轻量解析器：逐行读取，用状态机跟踪单引号/双引号、注释块、括号嵌套深度，仅在分号位于“语句末尾”时触发切分。示例核心逻辑：
in_string = False<br>depth = 0<br>for line in f:<br> for c in line:<br> if c == "'" and not in_comment:<br> in_string = not in_string<br> elif c == ";" and not in_string and depth == 0:<br> write_to_next_file()<br> # 其他状态更新...
更稳妥的替代方案：导出阶段就控制文件大小
与其事后切分，不如从源头避免大文件：
- 用
mysqldump --skip-extended-insert --quick：每行一个INSERT，虽略增体积但可安全用split -l切（前提是确认无长文本字段含换行） - 按表导出：
mysqldump -u user -p db_name table1 > table1.sql，再对单表文件单独处理 - 加条件导出：
mysqldump -u user -p db_name table --where="id BETWEEN 1 AND 10000"，配合循环导出分片 - 导出为 CSV：
SELECT * INTO OUTFILE '/tmp/data.csv' FIELDS TERMINATED BY ',' FROM table;，再用mysqlimport导入，绕过 SQL 解析瓶颈
真正麻烦的从来不是切分动作本身，而是切完后导入失败却找不到哪一行坏了——语句边界识别不到位，就是埋雷。宁可多花十分钟写个 Python 小脚本，也别信“split -l 2000 试试看”。
