校验失败时最常被忽略的是group_concat因group_concat_max_len默认1024导致的无声截断，需设为足够大；其次要注意cast统一类型、null处理、时区格式、order by确定性排序及blob/json安全转换。
校验失败时先确认GROUP_CONCAT长度是否截断
MySQL默认group_concat_max_len是1024，校验大字段或大量行时，GROUP_CONCAT生成的Hash串会被无声截断，导致两端结果不一致——这是最常被忽略的“假差异”。
- 执行
SELECT @@group_concat_max_len查当前值，迁移前务必设为足够大（如SET SESSION group_concat_max_len = 1000000） - 若用
mysqldump --tab导出再校验，需同步检查服务端和客户端的该参数，二者都得调大 - 截断不会报错，但
SELECT MD5(GROUP_CONCAT(...))结果会稳定不同，反复验证仍失败时优先怀疑这个
用CAST统一字段类型再哈希，避免隐式转换干扰
源库和目标库字段类型稍有差异（比如VARCHAR(255) vs TEXT、DATETIME vs TIMESTAMP），会导致相同逻辑值在哈希前被MySQL按不同规则格式化，最终MD5不一致。
- 校验SQL中所有参与拼接的字段，显式用
CAST(col AS CHAR)或CAST(col AS SIGNED)归一化 - 特别注意
NULL：GROUP_CONCAT默认跳过NULL，但两端NULL处理逻辑可能不同；建议统一写成IFNULL(CAST(col AS CHAR), 'NULL') - 时间字段务必转为统一时区+格式，例如
DATE_FORMAT(CONVERT_TZ(col, '+00:00', '+08:00'), '%Y-%m-%d %H:%i:%s')
分块校验时ORDER BY必须严格一致，否则Hash必然不同
没加ORDER BY的GROUP_CONCAT行为不可靠——InnoDB存储顺序不等于查询返回顺序，尤其跨版本或引擎（如MyISAM→InnoDB）时，同一数据集两次查询可能拼出不同字符串。
- 校验语句里
GROUP_CONCAT必须配合确定性排序，例如GROUP_CONCAT(...) ORDER BY id, created_at - 排序字段必须是联合唯一标识（不能只用
id，万一有重复），且确保索引存在，避免临时文件排序引入不确定性 - 分块校验时，每块的
LIMIT+OFFSET要和排序字段组合使用，例如WHERE id > ? ORDER BY id LIMIT 1000，别用OFFSET——它在大数据量下性能差还易漏行
遇到BLOB/JSON字段，别直接CAST AS CHAR
BLOB、JSON字段用CAST(... AS CHAR)可能触发乱码或截断，尤其含二进制内容或非UTF-8字符时，Hash结果完全不可信。
- 对
BLOB，改用HEX(col)转十六进制字符串再拼接，安全且可逆 - 对
JSON，优先用JSON_EXTRACT(col, '$')标准化结构，再REPLACE(REPLACE(...), '\n', '')清理空白（MySQL 5.7+支持JSON_PRETTY但慢，生产环境慎用） - 如果字段本身是加密或压缩内容（如AES_ENCRYPT结果），哈希前必须确认解密/解压逻辑两端完全一致，否则比的是“密文”而非“原文”
真正麻烦的不是算不出Hash，而是Hash算对了却因排序、NULL、时区、字符集这些细节错位——它们不报错，只悄悄让结果不等。
