应使用 grep -i "values (" 统计备份文件中数据行数，因其可准确匹配每条 values ( 对应的记录，再配合 sed 过滤注释、空行和结构语句可提升精度，避免误计。
直接 grep INSERT 会漏掉大块数据
备份文件里真正存数据的语句是 INSERT INTO ... VALUES (...),(...),(...); 这种批量插入格式，单行可能含几十上百条记录。用 grep "INSERT" 只能数出语句行数，不是真实行数——一条 INSERT 语句后面跟了 500 个括号，你得算 500 行，不是 1 行。
常见错误现象：看到备份文件有 200 行 INSERT 就以为只有 200 条数据；实际可能是 20 万条。
- 优先匹配
VALUES后面的括号对，而不是整行INSERT - 用
sed或awk拆分多值VALUES更可靠，但grep -o配合正则也能快速估算 - 如果备份用了
--skip-extended-insert（即每行一个VALUES），那grep "VALUES" | wc -l才真等于行数
用 grep -o 统计括号内的数据行
核心思路是把每个 (...) 当作一条逻辑记录来数。只要备份没禁用扩展插入，就靠这个：
grep -o "VALUES (.*?);" backup.sql | wc -l
但注意：GNU grep 默认不支持非贪婪匹配 .*?，所以得换写法：
grep -o "VALUES (" backup.sql | wc -l
这个更稳——它数的是 VALUES ( 出现次数，基本等价于数据行数（除非手写 SQL 里有注释或字符串含 VALUES (，概率极低）。
- 若备份含大量注释或特殊字符，加
-v "^--"排除注释行：grep -v "^--" backup.sql | grep -o "VALUES (" | wc -l - 区分大小写？MySQL dump 默认全小写，但保险起见加
-i：grep -i "values (" - 结果偏高？检查是否混入了
CREATE TABLE里的默认值定义（极少），可加| grep -v "DEFAULT ("
跳过注释、空行和结构语句再统计
原始备份文件常含 CREATE TABLE、SET、DELIMITER、空行、注释，直接 grep 容易误计。建议先过滤再数：
sed -e '/^--/d' -e '/^$/d' -e '/^CREATE/d' -e '/^SET/d' -e '/^DELIMITER/d' backup.sql | grep -i "values (" | wc -l
这条命令干了五件事：删注释、删空行、删建表语句、删配置语句、删分隔符声明——只留下纯数据插入行。
- 如果备份用了
--no-create-info，可省略/^CREATE/d -
sed多次-e效率比管道串多个grep -v高，尤其大文件 - 别用
cat backup.sql | sed ...，直接让sed读文件更省内存
为什么不能直接用 mysql -e "SELECT COUNT(*)"？
因为你要的是「备份文件里有多少行数据」，不是「恢复后表里有多少行」。这两者可能差很多：
- 备份时表被删了一半，但 dump 文件还没清理——文件里仍含所有旧数据
- 备份含
INSERT IGNORE或REPLACE，恢复时部分行被跳过或覆盖 - 备份跨事务，部分
INSERT被回滚但已写入 dump（极少见，但 mysqldump 加了--single-transaction就不会） - 你根本不想恢复，只想知道这个 2GB 的
.sql文件到底塞了多少条记录
这时候，基于文本的 grep + wc 是唯一不依赖 MySQL 实例、不触发恢复、秒级出结果的方式。精度够用，误差通常在 0.1% 以内——只要你没手动编辑过 dump 文件里的 VALUES 行。
