pt-table-checksum不能直接比对备份sql文件与线上库，必须先将备份导入为临时运行库，因其依赖实时mysql连接、information_schema查询、分块校验及checksums表写入，无法解析.sql文件。
pt-table-checksum 不能直接比对备份文件和现网库，它只校验正在运行的 MySQL 实例之间的数据一致性。 想用它对比“备份 SQL 文件”和“线上库”，必须先把备份导入成一个临时库，再让 pt-table-checksum 连这两个运行中的库去跑——否则命令会直接报错或无意义地扫空表。
为什么 pt-table-checksum 不接受 .sql 文件作为输入
这个工具底层依赖 MySQL 的复制机制和 information_schema 实时查询，它需要：
- 能执行
SELECT和REPLACE INTO的活跃连接 - 访问
INFORMATION_SCHEMA.TABLES获取表结构与行数 - 在目标库上创建校验专用的
percona.checksums表 - 对每张表分块计算 CRC32 或 MD5，并写入 checksums 表供后续比对
你丢一个 backup.sql 给它，它既读不了文件，也找不到表元数据，更没法建 checksums 表——错误典型是 DBI connect failed: Unknown database 'backup.sql' 或直接退出无输出。
想用 pt-table-checksum 对比备份与线上，必须先导入备份
导入不是随便 mysql -u -p db 就完事。容易踩的坑有：
-
backup.sql若含CREATE DATABASE，导入前得手动删掉，否则可能覆盖线上库名或权限冲突 - 导入用户必须有
SELECT、INSERT、UPDATE、DELETE、CREATE、DROP权限，且对目标库名（如db_backup）有完全控制权 - 字符集不一致会导致 checksum 计算错位，导入命令要加
--default-character-set=utf8mb4 - 大备份导入后建议
ANALYZE TABLE一次，避免因统计信息陈旧导致pt-table-checksum分块不准、超时或漏检
导入示例：
mysql -h127.0.0.1 -uuser -ppass --default-character-set=utf8mb4 db_backup <h3>运行 pt-table-checksum 的最小安全参数组合</h3><p>别裸跑默认参数，尤其在线上主库。关键控制点：</p>
- 加
--no-check-binlog-format：避免因 binlog_format 不是 STATEMENT 而拒绝执行 - 加
--replicate=percona.checksums：指定校验结果存哪，必须提前在目标库建好该表（pt-table-checksum --create-replicate-table可代劳） - 加
--chunk-size=1000或按实际调整：防止单次扫描锁表太久；太小则网络开销大，太大易超时 - 加
--databases=db_name显式限定范围，别让它扫整个实例 - 加
--recursion-method=none：禁用从SHOW SLAVE HOSTS自动发现从库，避免误连其他环境
执行命令示例：
pt-table-checksum --host=127.0.0.1 --user=user --password=pass \ --databases=db_name \ --replicate=percona.checksums \ --chunk-size=1000 \ --no-check-binlog-format \ --recursion-method=none
比对结果怎么看，哪里最容易误判
校验完成后，查 percona.checksums 表：
SELECT * FROM percona.checksums WHERE this_crc != master_crc OR is_crc = 0;
但注意：
-
this_crc != master_crc真正代表数据不一致，但前提是两个库的server_id不同且没被设成一样（否则它会把本库当“master”自比） -
is_crc = 0表示某块没成功计算，可能是超时、锁冲突或字段类型不支持（比如 JSON 字段在老版本 MySQL 中 CRC 计算不稳定） - 如果线上库开了
sql_log_bin=0，checksum 写入不会记 binlog，从库就收不到，master_crc始终为空，所有行都显示不一致——这是配置陷阱，不是数据问题 - 时间字段（
DATETIME）若线上库开了explicit_defaults_for_timestamp=OFF，而备份库是 ON，NULL 插入行为不同，CRC 必然不等
真正要盯的是 this_crc 和 master_crc 都非空且不等的记录，再结合 chunk_start/chunk_end 定位到具体主键范围，用 SELECT ... WHERE id BETWEEN x AND y 手动抽样确认。
