mysqldump单文件不适合直接恢复，因易因内存不足、超时或中断失败，且无法跳过损坏片段、并行导入或按需恢复某几张表；必须按分号结尾的完整SQL语句切分，并统一处理外键与DDL重复问题。
为什么 mysqldump 生成的单文件不适合直接恢复？
大库导出的 mysqldump 文件常达数 GB，直接用 mysql 命令恢复容易因内存不足、超时或网络中断失败；更关键的是，无法跳过损坏片段、无法并行导入、也无法按需恢复某几张表。这不是“能不能”的问题，而是“稳不稳”和“灵不灵”的问题。
用 split 拆分逻辑备份文件但保留 SQL 完整性
不能简单按字节切分，否则会把一条 INSERT 语句或事务拆成两半。必须按 SQL 语句边界切分，即以分号 ; 结尾的完整语句为单位。
- 先确保原始 dump 文件使用
--skip-extended-insert（每行一个INSERT），或用--skip-extended-insert --complete-insert提高可读性和可切分性 - 用
awk或 Python 脚本识别;结尾且不在引号/注释内的语句，再按行数或大小（如每 5000 条语句）写入新文件 - 避免用
split -l直接切行：它不管 SQL 语法，大概率在VALUES (...,中间断开，恢复时报错ERROR 1064 (42000) - 示例简易切分（仅适用于无嵌套分号、无存储过程的纯 DML）：
awk '/;$/ {n++; if(n%5000==1) close(f); f="dump_part_" int((n-1)/5000)+".sql"; print > f; next} {print > f}' full_backup.sql
分卷恢复时如何避免重复执行与外键冲突
拆分后的多个 SQL 文件若直接顺序执行，可能因部分文件含 CREATE TABLE + INSERT，而另一份又含相同 CREATE TABLE 导致 ERROR 1050 (42S01)；同时未关外键检查会导致 INSERT 失败。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 所有分卷文件开头统一加
SET FOREIGN_KEY_CHECKS=0;，结尾加SET FOREIGN_KEY_CHECKS=1; - 只在第一个分卷中保留
CREATE DATABASE和CREATE TABLE语句，其余分卷删掉这些 DDL（可用sed -n '/^CREATE TABLE /,/^;/!p' file.sql > clean.sql过滤） - 用
mysql -u user -p db_name 恢复首卷后，后续卷改用mysql -u user -p db_name --force ，让报错不中断流程（--force对重复建表等错误静默跳过） - 别依赖
source命令分卷：它在 MySQL 客户端里不支持变量、不兼容部分注释格式，且无法捕获子文件错误码
真正需要分卷恢复的场景其实很有限
多数情况下，与其折腾拆分，不如优化原始备份方式：用 mysqldump --single-transaction --routines --triggers --databases db1 db2 分库导出，或直接用 mydumper（天生支持多线程+分表输出）。只有当必须用单个 dump 文件、又受限于磁盘 I/O 或恢复环境内存极小时，才值得投入精力做语句级切分与带状态恢复。
最易被忽略的一点：拆分脚本本身必须能重入，且每份输出文件末尾必须是完整语句——哪怕只剩一个 COMMIT;，漏掉它就可能让事务卡在未提交状态，后续恢复数据不一致。
