mysql如何快速定位主从不一致的表_使用checksum

CHECKSUM TABLE 在 MySQL 8.0.29+ 中已被彻底移除，8.0.22 起弃用；执行将报错 FUNCTION does not exist；可用 MD5(GROUP_CONCAT()) 等手动方案替代。

mysql如何快速定位主从不一致的表_使用checksum_table命令

checksum_table 在 MySQL 8.0+ 中已不可用

CHECKSUM TABLE 命令在 MySQL 8.0.29 及之后版本被彻底移除，8.0.22 起已标记为弃用。如果你在 8.0+ 环境下执行它，会直接报错：ERROR 1305 (42000): FUNCTION db.CHECKSUM_TABLE does not exist 或类似提示。这不是权限或语法问题，是功能删除。别浪费时间查用户权限或拼写——它就是没了。

替代方案：用 MD5(GROUP_CONCAT()) 手动构造校验和

小表（行数

必须按主键/唯一索引排序，否则 GROUP_CONCAT 结果不可比：SELECT MD5(GROUP_CONCAT(CONCAT(id, ':', COALESCE(name, 'NULL'), ':', COALESCE(status, 'NULL')) ORDER BY id SEPARATOR '|')) FROM user;
提前调大长度限制，避免截断：SET SESSION group_concat_max_len = 10000000;
所有字段必须显式 COALESCE 处理 NULL，否则 NULL 参与拼接会导致整个结果为 NULL
字符集不一致时，MD5 结果不同——务必确认主从表的 COLLATE 相同，比如都为 utf8mb4_bin

为什么不能只比 COUNT(*)？

只查 COUNT(*) 容易漏掉“数据存在但内容错误”的情况。例如主库某行 status = 'paid'，从库同步成 'payed'（拼写错误），行数完全一致，但业务已受损。更危险的是：主库有脏数据（如重复主键被忽略）、从库因 1062 错误跳过插入，也会表现为行数相同但实际记录不同。所以必须校验内容本身，而非仅数量。

kashen-mysql DDLtoExcel

解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。

下载

真正该用的工具是 pt-table-checksum

生产环境别手写校验逻辑。它自动分块、适配 ROW 格式 binlog、处理大表、支持 GTID、结果写入表可追溯。执行前只需确保：

主库 binlog_format = ROW（pt-table-checksum 默认拒绝 STATEMENT 格式）
校验用户有 REPLICATION CLIENT 和 SELECT 权限
从库 read_only = ON（防止修复过程中被写入干扰）
先跑 pt-table-checksum --nocheck-replication-filters --replicate=test.checksums h=master_host，再查 SELECT * FROM test.checksums WHERE this_crc != master_crc;

手动拼 MD5 仅适用于临时排查、无 Percona Toolkit 权限、或极小范围验证。一旦涉及多表、大表、或需要留痕审计，pt-table-checksum 是唯一合理选择——不是因为它“高级”，而是因为复制场景下的分块校验、事务边界、字符集容错等细节，手写根本覆盖不全。