pt-table-checksum 连不上从库主因是从库连接配置或权限问题：需确保 report_host/port 正确、从库开放远程访问、用户具备 replication client 和 select 权限，并注意 mysql 8.0+ 认证插件兼容性。
pt-table-checksum 连不上从库怎么办
pt-table-checksum 默认会自动发现从库并连接校验，但常见报错是 Can't connect to slave 或 Access denied。根本原因不是工具问题，而是它需要在从库上执行 SHOW SLAVE STATUS 和部分元数据查询，所以必须用有权限的账号连从库本身（不只是主库）。
- 主库和从库的
report_host、report_port必须配置正确，否则pt-table-checksum会按SHOW SLAVE HOSTS返回的地址去连，而这个命令早已被弃用且常为空 - 从库要开放远程连接（
bind_address不能是127.0.0.1），且用户需有REPLICATION CLIENT+SELECT权限 - 如果用的是 MySQL 8.0+，注意默认认证插件是
caching_sha2_password，而老版本pt-table-checksum（如 Percona Toolkit 3.1.x）可能不兼容，得降级插件或升级工具
示例检查命令：
mysql -h slave_ip -u checksum_user -p -e "SHOW SLAVE STATUS\G"
校验结果里为什么显示 chunk 跳过或不一致却没报错
pt-table-checksum 的默认行为是跳过无法加锁或查询超时的表/分块（chunk），并在输出末尾汇总为 Skipped 行；而不一致（Diffs）只在启用 --replicate 表后才写入，且需配合 pt-table-sync 才能定位具体行。
- 不一致不等于数据不同，可能是主从复制延迟导致校验期间从库还没追上，建议先确认
Seconds_Behind_Master为 0 再跑 -
--replicate指定的表必须存在于所有从库上，且工具会往该表写 checksum 结果，如果从库该表被误删或权限不足，就只会显示0 diffs却实际漏检 - 默认每 chunk 最大 1000 行，遇到大字段或慢查询容易超时，可调
--chunk-size或--chunk-time，但别设太大，否则锁表时间长影响业务
pt-table-checksum 和 pt-table-sync 配合修复时踩什么坑
pt-table-sync 不是“一键修复”，它本质是生成 SQL 并在从库回放，风险极高，必须提前验证。
- 它默认只输出 SQL（
--print），不执行（--execute需显式加），但很多人漏看这一步，直接上线执行导致从库写入爆炸 - 工具识别“哪边是源”依赖
--sync-to-master或--slave参数，如果主从角色判断反了，就会把从库数据当成源，反向覆盖主库 - 对于有自增主键、触发器、外键约束的表，
pt-table-sync生成的 REPLACE/INSERT 可能失败，得加--no-check-triggers或手动处理 - 它不校验逻辑一致性（比如金额字段是否被业务逻辑二次更新），只比对当前快照值，所以修复后还得结合业务日志交叉验证
MySQL 8.0.26+ 开启 binlog_row_metadata=FULL 后 checksum 失败
这是个隐蔽但高频的问题：新版 MySQL 在开启 binlog_row_metadata=FULL 后，会把列的 COLLATION、CHARACTER_SET 等元信息写入 binlog，而 pt-table-checksum 旧版本解析时会因字段类型不匹配报错 Column count doesn't match value count。
- 目前稳定解法是升级 Percona Toolkit 到 3.5.0+，它已适配该 binlog 格式变化
- 临时绕过可关掉该参数（
SET GLOBAL binlog_row_metadata=MINIMAL），但会影响 GTID 复制稳定性，不推荐长期使用 - 另一个信号是
pt-table-checksum日志里出现大量Unknown column type: 254，这就是元数据扩展字段的标识符
校验这事，最难的从来不是跑通命令，而是搞清哪一环在“假装一致”——比如从库 IO 线程挂着但 SQL 线程卡住，或者 checksum 表本身在某个从库上被 truncate 过。多看一眼 SHOW SLAVE STATUS 的每个字段，比反复重跑工具管用得多。
