pt-table-checksum在从库误写入（read_only=OFF）时会直接报错退出，拒绝校验；必须先停写主库、STOP SLAVE并设read_only=ON，再用pt-table-sync --sync-to-master配合--print预览修复SQL，修复后须重新校验DIFFS=0并验证Exec_Master_Log_Pos是否正常前进。
从库误写入后，pt-table-checksum 会直接报错退出
只要从库开启了 read_only = OFF 并被应用或人肉写入过，pt-table-checksum 在主库上一执行就会失败，错误类似：DBD::mysql::db do failed: Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. 或更常见的：Slave SQL thread is running, but checksums cannot be computed on slaves with active replication threads. —— 它不是“算不准”，而是拒绝在有潜在污染风险的环境下工作。这时候别硬跑校验，先确认写入范围。
确认误写入影响范围：查 information_schema.tables 和 binlog
误写入不等于全库污染，往往只涉及几张表。优先定位：
- 用
SELECT table_schema, table_name FROM information_schema.tables WHERE table_schema NOT IN ('mysql','sys','information_schema','performance_schema');拿出所有业务库表清单 - 登录从库，执行
SHOW BINLOG EVENTS IN 'mysql-bin.000001' LIMIT 20;（替换为实际 binlog 文件名），看最近是否有非复制来源的INSERT/UPDATE/DELETE事件，重点关注server_id是否与主库一致 - 对比主从的
SELECT COUNT(*)和CHECKSUM TABLE（仅限小表），快速筛出明显异常的表；大表跳过，避免锁表和IO风暴
修复必须分两步：停写 + 覆盖，不能边跑边修
数据分叉没有“在线修复”这回事。MySQL 复制协议本身不提供冲突合并逻辑，pt-table-sync 也不是智能 merge 工具，它默认行为是“目标库覆盖源库”，也就是把从库当成脏数据源，强制用主库值覆盖过去。所以操作顺序不可颠倒：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 业务侧必须停写主库（或切到只读），确保主库不再产生新 binlog
- 从库执行
STOP SLAVE;，再设SET GLOBAL read_only = ON;，彻底阻断任何写入可能 - 运行
pt-table-sync --sync-to-master --replicate=test.checksums h=192.168.1.1,u=replicator,p=xxx h=192.168.1.2（注意顺序：主库在前，从库在后） - 加
--dry-run和--print先预览要执行的 SQL，确认无 DROP/ALTER 等高危操作再真实执行
修复后必须验证，且不能只信 Seconds_Behind_Master = 0
复制线程显示追平，不代表数据真一致。常见陷阱：
-
Seconds_Behind_Master为 0 只说明 relay log 已回放完，但若中间有DROP TABLE或TRUNCATE，从库表结构可能已不同 - 务必对修复过的表单独跑
pt-table-checksum（此时从库已停写、主库只读），确认DIFFS列为 0 - 检查从库
SHOW SLAVE STATUS\G中的Exec_Master_Log_Pos是否持续前进，避免因sql_slave_skip_counter导致跳过关键事件而“假同步”
最麻烦的点在于：一旦误写入跨了多个事务、混在正常复制流里，人工很难精准剥离。这种情况下，重建从库反而是更省事的选择——毕竟 MySQL 5.7 的 GTID 在位点对齐上已经足够可靠，比在脏数据上反复修补更可控。
