mysql dump 文件是纯文本sql脚本，需流式逐行解析并状态机处理insert语句，避免正则与全量加载；对--tab输出应优先用mysqlimport或load data infile；须严格处理utf-8多字节与null字面量。
MySQL dump 文件不是二进制格式，本质是可执行 SQL 脚本
直接拿 C++ 去“解析” mysqldump 生成的文件，前提是得先认清它的结构：它不是数据库快照或序列化二进制，而是由 CREATE DATABASE、CREATE TABLE、INSERT INTO ... VALUES (...),(...) 等标准 SQL 语句组成的纯文本。所以所谓“解析”，其实是 SQL 文本的分块、语法识别与上下文还原，而非反序列化。
常见误判点：
- 试图用二进制读取器（如
fread+ struct 映射）处理.sql文件 → 必然失败，内容全是 ASCII/UTF-8 文本 - 把
mysqldump --tab输出的.txt和.sql混为一谈 → 前者是字段分隔的纯数据，后者是完整 DDL+DML - 忽略
/*!40101 SET ... */这类条件注释 → 它们是 MySQL 扩展语法，在非 MySQL 环境下会被当普通注释跳过，但 C++ 解析器若不识别，可能误判语句边界
逐行读取 + INSERT 语句拆分是大规模导入最稳的路径
面对 GB 级 mysqldump 文件（比如单表千万行），不能一次性 std::ifstream::read 全部进内存，更不能用 std::regex 全局匹配所有 INSERT —— 正则回溯会爆炸，内存占用不可控。
推荐做法是流式分块处理：
- 用
std::getline逐行读取，跳过空行、注释行（以--、#或/*开头） - 检测到
INSERT INTO `table_name` VALUES开头时，开始累积行，直到遇到分号;结尾（注意：VALUES 内部可能含转义分号或换行，需简单状态机判断括号嵌套） - 对每条完整
INSERT，提取表名和值列表，转换为std::vector<:vector>></:vector>或批量绑定参数传给 MySQL Connector/C++ - 每处理 N 条（如 1000）就执行一次
INSERT批量插入，避免单语句过长触发max_allowed_packet限制
示例关键逻辑片段（伪代码）：
std::string line;
while (std::getline(in, line)) {
if (line.empty() || starts_with(line, "--") || starts_with(line, "#")) continue;
if (starts_with(line, "INSERT INTO")) {
std::string stmt = line;
while (!ends_with(stmt, ";")) {
std::getline(in, line);
stmt += "\n" + line;
}
parse_and_batch_insert(stmt); // 自定义解析函数
}
}
绕过 SQL 解析：用 mysqlimport / LOAD DATA INFILE 更高效
如果原始 dump 是用 mysqldump --tab 生成的（即分离出 .sql 表结构 + .txt 数据文件），C++ 完全不需要解析 SQL —— 直接调用系统命令触发 mysqlimport，或让 MySQL 执行 LOAD DATA INFILE。
这比手写 C++ 解析快一个数量级，因为绕过了文本解析、字符串分割、SQL 语法校验等开销：
-
mysqlimport是 C 实现的命令行工具，专为大文件设计，支持多线程、字段映射、错误跳过等 - 在 C++ 中用
std::system("mysqlimport --local -u user -p pwd db table.txt")即可，但要注意 shell 注入风险，应拼接绝对路径并校验文件名 - 若必须走 MySQL 协议，可用 Connector/C++ 执行
LOAD DATA LOCAL INFILE '/path/to/data.txt' INTO TABLE t FIELDS TERMINATED BY '\t'，前提是服务端开启local_infile=ON且客户端启用CLIENT_LOCAL_FILES标志
字符编码与 NULL 字段是 C++ 解析时最容易崩的两个点
MySQL dump 默认用数据库当前字符集导出（如 utf8mb4），而 C++ std::string 不带编码语义。一旦遇到 emoji 或中文，用 std::string::find(",") 分割字段会切在 UTF-8 多字节中间，导致后续解析错位。
NULL 值在 dump 中写作 NULL（不带引号），但字符串字段里的 'NULL'（带单引号）是字面量。两者必须严格区分：
- 字段值若为
NULL（无引号、全大写、前后空格可选），应映射为std::nullopt或专用空标记 - 字段值若为
'NULL'或"NULL"，是字符串，需去掉引号并保留原内容 - 建议用轻量 tokenizer（如基于
std::string_view的状态机）替代std::stringstream >>，前者可控、无隐式跳过空白行为
真正卡住项目的，往往不是百万行怎么读，而是第 127493 行里那个没转义的单引号，或者第 882101 行里一个被截断的 UTF-8 字节序列 —— 这些必须在 tokenizer 层就捕获并报明确位置，而不是等到执行 SQL 时报 ERROR 1300 (HY000): Invalid utf8mb4 character string 才回头查。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
