pt-table-checksum 连不上目标库主因是权限或网络配置错误，需确保运行机可访问从库 IP+ 端口，账号具备 SELECT/PROCESS/SUPER 权限，bind_address 非 127.0.0.1，且显式指定配置段。
pt-table-checksum 连不上目标库怎么办
pt-table-checksum 执行时抛出 DBI connect failed: Access denied 或 Can't connect to MySQL server，基本是权限或网络配置没对上。它默认用主库账号连从库（不是反向），所以得确保运行命令的机器能访问从库 IP + 端口，且账号在从库上有 SELECT、PROCESS、SUPER（或 REPLICATION CLIENT）权限。
- 检查从库
bind_address是否为127.0.0.1（导致远程连不上），应设为0.0.0.0或具体 IP - 在从库执行
SHOW GRANTS FOR 'user'@'%';，确认有SELECT权限且 host 匹配调用方 IP - 如果用 SSH 隧道，
--host要填127.0.0.1，但--port得填隧道映射的本地端口，别直接写从库真实端口 - 不要依赖
~/.my.cnf里的 [client] 段——pt-table-checksum只读 [pt-table-checksum] 段，必须显式加--config或把参数全打出来
校验结果里出现大量 CHUNKS_DIFF > 0 怎么定位
CHUNKS_DIFF 不为 0，只说明某张表的某个分块校验值不一致，不代表整张表都错。真正要盯的是 DIF 列（即 DIFF）是否为 1，以及 TS 时间戳是否最新——老的校验记录可能残留，干扰判断。
- 先跑
pt-table-sync --print --sync-to-master h= 从库 IP,u= 用户，p= 密码，它会输出具体哪几行不一致（不实际同步，纯预览） - 注意：如果从库开了
read_only=1，pt-table-checksum默认会在从库建percona.checksums表，这时会失败；得加--replicate-db percona并提前在主库建好该库，让 checksum 写主库再复制过去 - 时间字段类型为
DATETIME(6)或带时区的TIMESTAMP，主从时区设置不同会导致校验值不等，检查双方SELECT @@time_zone;
为什么校验完显示 0 DIFF 却还是不敢上线
pt-table-checksum 默认只校验 ENGINE=InnoDB 表，跳过 MyISAM、临时表、系统表。如果迁移过程混用了引擎，或者有 VIEW、TRIGGER、ROUTINE，它完全不碰。
- 加
--all参数不会包含视图，得单独用SELECT对比视图结果集 - 自增主键如果在从库被手动插入过数据，可能导致后续自增值偏移，但
pt-table-checksum校的是内容哈希，不校 ID 序列——得额外用SELECT MAX(id) FROM tbl对比 - 大表（比如 >50GB）校验时若没加
--chunk-size，可能因单块超时中断，日志里会出现Chunk failed，但返回码仍是 0，容易误判
替代方案：不用 pt-tool 怎么快速兜底
不是所有环境都能装 Percona Toolkit，尤其容器或受限主机。可以用原生 SQL + 简单脚本组合：
- 对每张表跑：
SELECT COUNT(*), MD5(CONCAT_WS('#', col1, col2, ……)) FROM tbl（注意 NULL 要转成字符串，否则CONCAT_WS会丢整行） - 主从分别导出结果到文件，用
diff对比——但别直接mysqldump --skip-extended-insert，因为插入顺序不确定，MD5 会变 - 更稳妥的是按主键排序后逐行算哈希：
SELECT id, MD5(CONCAT_WS('#', coalesce(col1,''), coalesce(col2,''))) FROM tbl ORDER BY id，两边取前 1000 行哈希比对，覆盖热点数据
校验这事，最难的不是工具怎么跑，而是搞清「到底要证明什么」——是行数一致？内容一字不差？还是业务可接受的误差范围？漏掉这个前提，后面所有 pt-table-checksum 参数都是白调。
