pt-table-sync必须先运行pt-table-checksum，因其本身不比对数据，仅读取percona.checksums表中的DIFFS和分块范围；无该表或全为0则直接退出，无法定位差异。
pt-table-sync 不能自动修复——它必须依赖 pt-table-checksum 的校验结果，且所有修复操作都需人工确认；跳过 --print 直接 --execute 等同于在生产库上盲执行 DELETE/REPLACE，风险极高。
为什么 pt-table-sync 必须先跑 pt-table-checksum？
pt-table-sync 本身不比对数据，只读取 percona.checksums 表里的 DIFFS 和分块范围。没这张表，或表里全是 0，它就无事可做，直接退出。
- 主库执行
pt-table-checksum后，会把每张表每个 chunk 的 CRC32 校验和写入指定库表（默认percona.checksums） - 从库靠复制机制同步该表内容，再用自身数据重新计算校验和，与主库写入的值比对
- 若
DIFFS = 1，说明该 chunk 行级不一致；ERRORS > 0则大概率是字符集、排序规则或字段类型不一致导致校验失败 - 常见报错
No slaves were found：主库未设report_host，需加--recursion-method=dsn显式指定从库地址
怎么安全执行 pt-table-sync 修复？
核心原则：只在主库执行修改语句，靠复制同步到从库；所有操作必须先 --print 预览。
-
--sync-to-master是关键开关：它让工具生成的INSERT ... ON DUPLICATE KEY UPDATE或DELETE全部在主库运行，避免直写从库引发复制断裂 - 典型命令：
pt-table-sync --print --replicate=percona.checksums --sync-to-master h=192.168.184.152,u=dba,p=Id81Gdac_a --databases=maria - 输出里看到
DELETE FROM `maria`.`t_user` WHERE id = 123这类语句时，务必确认：这是从库多出的脏数据，还是业务双写遗留的合法记录？ - 若输出大量
DELETE，尤其涉及订单、资金类表，建议先手动START TRANSACTION执行几条，验证权限和逻辑
遇到 Cannot chunk table 错误怎么办？
这是最常卡住的点：表没有主键或唯一索引，或字符型主键前缀高度重复（如全以 U_ 开头），pt-table-sync 默认拒绝分块处理。
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 报错示例：
Cannot chunk table dbname.opt_log using the character column opt_id, most likely because all values start with the same character - 临时绕过：加
--algorithms=Nibble（逐行扫描，慢但能过），或--no-check-plan（跳过计划检查，风险自担） - 根治方法：给表加主键，例如
ALTER TABLE dbname.opt_log ADD id BIGINT AUTO_INCREMENT PRIMARY KEY FIRST - 注意：加主键前先确认字段类型兼容现有数据，避免
Incorrect integer value类报错
修复后最容易被忽略的三件事
修复完成≠万事大吉。很多故障复发，就因为这三步没做：
- 立刻在从库执行
SHOW SLAVE STATUS\G，确认Slave_SQL_Running: Yes、Seconds_Behind_Master = 0、且Last_SQL_Error为空 - 重新跑一次
pt-table-checksum，查SELECT db,tbl,DIFFS FROM percona.checksums WHERE DIFFS != 0，确保全部归零 - 检查被修复的表是否含外键约束——
pt-table-sync不处理级联，若父表被删而子表未同步，后续 INSERT 可能触发ERROR 1452
