【 TiDB 使用环境】生产环境
【 TiDB 版本】tidb6.1.1，sync_diff_inspector v2.0
【遇到的问题】sync-diff-inspector 数据校验表结构不一致（上游mysql，下游tidb）
【复现路径】
步骤：
1. 用dumpling 导出上游mysql表结构及数据
2. 用lightning 导入tidb
3. 第一步的时候，导出的表结构中，自动加上了 COLLATE=utf8_bin 的选项
4. 使用 sync-diff-inspector 数据校验，告知两个表的表结构不一致
线上几十个表都等着数据校验呢，这可怎么搞？？
没人回答这个问题吗。。。 
各位大神帮帮忙呀~
这里我填过 collation = “utf8_bin” 或者 collation = “utf8_general_ci”， 都没用啊？ 这个参数具体咋用？ 而且，有个疑问，提示表结构不一致，但是哪儿不一致，又没提醒或者日志输出？
看了，看了好几遍了。。。你不信 自己找找，表结构不同时，会在哪儿打印？ 
之前有集中弄过数据校验这个问题，正好能来聊聊。
这个错误原因在于 这个工具是分片然后比对的。
分片必然涉及到排序然后切分，但是如果 collation 不一致的话，会导致按照同样的方式切分出来的不一致。
有一个解决办法是在 select 时显式指定 collate， 但会用到外排，从而大大降低效率。
最后我们没有用这个 sync-diff, 改了一个其他的数据校验工具来用的。
请问最后你们用了哪个工具？
一个上游源的厂商提供的工具，目前应该还没有对外开放，我们进行了修改。
是这样的：
我一开始反馈的问题，后来排查发现是因为上下游表结构不一致，主库里没索引，备库里有索引，同步是跟主，校验是跟备，所以一开始排查问题不对，报错原因不是collation，就是因为索引缺失导致。
而后来我发的截图报错，的确是因为chunk计算不对导致的同步失败。
我这里也说一下我的解决办法吧：
我一开始反馈的问题，后来排查发现是因为上下游表结构不一致，主库里没索引，备库里有索引，同步是跟主，校验是跟备，所以一开始排查问题不对，报错原因不是collation，就是因为索引缺失导致。
→ 解释的有问题，“使用 sync-diff-inspector 数据校验，告知两个表的表结构不一致” 应该是报错确实指出这个 collation 的区别。绕过方法 collate 才应该是解决这个问题的方法。（第一处因果对应不上）
而后来我发的截图报错，的确是因为chunk计算不对导致的同步失败。
→ chunk 计算不对，就是说明存在数据不一致的情况。sync-diff 是基于索引去分 chunk，然后上下游同时 取 chunk 内的 cdc32 计算结果。也就是说，如果 chunk 不对，那么就是数据不一致（也可能是上下游分 chunk 的有问题）。（chunk 计算不对，不能算根因，只能算现象）
把校验涉及的表都看一下表结构，把所有text、blob、json格式的都忽略校验，大概率有用
→ 这个大概率有用，不太清楚其中所谓的有用的原理是绕过了哪一步。
调整下chunk_size，有时候有用
–>可能对于小表来说，可能直接就走全表扫描了，不会用索引区分 chunk，可能和下面的有点一个意思得感觉。（个人猜测）
不单独设置该表的校验规则，让工具自己去全表操作扫描，有时候有用
→ 也不清楚现象和其中原理。
不过，我觉得你的下游可能存在索引数据不一致的情况，
建议还是做做 admin check table，别以后生产出事。
谢谢答复~ 我这个问题以及我自己答复的那些措施 对应解决的都是很多库表的情况，不是单指一个库表的情况~ 至少现在来看，目前每日的检测任务都稳定了，也没存在其他问题了。
官方也建议忽略某些特定类型的列：
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。
