pt-table-checksum 连不上从库主因是权限或网络配置错误：需确保校验账号在从库有SELECT+PROCESS权限，检查skip-networking和绑定地址，GTID环境下必须用--recursion-method=dsn指定从库DSN。
pt-table-checksum 连不上从库怎么办
根本原因通常是权限或网络配置没对，不是工具本身有问题。pt-table-checksum 默认用主库账号去连从库，但很多环境从库只开了复制账号（如 repl），没给校验账号读表权限。
- 确保校验用的 MySQL 账号在从库上也有
SELECT+PROCESS权限，不能只靠主库账号自动同步过去 - 检查
my.cnf里从库是否禁用了skip-networking或绑定了127.0.0.1，导致pt-table-checksum从主库机器发起连接时被拒 - 如果用了 GTID，必须加
--recursion-method=dsn并指定从库 DSN，否则它会跳过从库发现逻辑
校验结果里 checksum_diff=1 却没报错
这是 pt-table-checksum 的默认静默行为：只要没遇到致命错误（比如连不上、锁超时），它就只把差异写进 percona.checksums 表，不中断执行也不 stdout 输出警告。
- 必须手动查
SELECT * FROM percona.checksums WHERE master_cnt != this_cnt OR master_crc != this_crc OR ISNULL(master_crc) XOR ISNULL(this_crc); - 注意
master_cnt和this_cnt是行数，master_crc/this_crc是 CRC32 校验值；任一不同都代表数据不一致 - 如果从库开启了
read_only=1，但percona.checksums表是 InnoDB，且事务中被其他长事务阻塞，可能导致某张表校验值没写入从库，看起来像“漏检”
大表校验卡住或拖慢线上业务
pt-table-checksum 默认对每张表加 READ LOCK（MyISAM）或走 SELECT ... FOR UPDATE（InnoDB），高峰期容易引发锁等待和主从延迟加剧。
- 强制用 chunk 方式分片校验：
--chunk-size=10000（按行数）或--chunk-index=PRIMARY（避免全表扫描） - 避开业务高峰，加
--sleep=0.1控制每 chunk 后休眠时间，减小 I/O 冲击 - 禁止校验系统表和日志表：
--ignore-databases=mysql,information_schema,performance_schema - 如果表没主键或唯一索引，
pt-table-checksum会退化成单 chunk 全表扫，务必提前用SHOW CREATE TABLE检查
为什么 --replicate 参数必须指向同一个库表
--replicate=percona.checksums 不是随便起个名字就行，这个库表必须在所有参与校验的实例上都存在、结构一致，且从库能写入（哪怕只是临时写 checksum 结果）。
- 不能写成
--replicate=test.checksums然后只在主库建表——从库不会自动创建，校验结果无法落地 - 如果从库开了
super_read_only=1，得先临时关掉：SET GLOBAL super_read_only=0;，否则写percona.checksums失败，差异永远看不到 - 表引擎必须是 InnoDB（官方文档明确要求），MyISAM 在从库可能因并发写入导致 checksum 记录错乱
真正麻烦的是跨版本或字符集混用场景：比如主库是 utf8mb4_0900_as_cs，从库是 utf8mb4_general_ci，CRC 计算结果天然不同，但工具不会提示——得人工核对 collation 设置。
