一个好的问题描述有利于社区小伙伴更快帮你定位到问题，高效解决你的问题
【TiDB 使用环境】生产环境
【TiDB 版本】 7.5.6
【部署方式】机器部署
【操作系统/CPU 架构/芯片详情】 centos 7.9
【机器部署详情】CPU大小/内存大小/磁盘大小
【集群数据量】
【集群节点数】
【问题复现路径】
【遇到的问题：问题现象及影响】
在有问题的 tidb server 上执行语句：
有问题的那个节点有报错: [ERROR] [reporter.go:218] [“indexLookup found data inconsistency”]。
在有问题的节点上执行 admin check table 也没有问题：
目前定位问题范围缩小到 tidb server 解析 65 这个数字存在问题：
这报错是 IndexLookUp 回表时索引值和行值比对不上（consistency/reporter.go 那套，跟 admin check 不是一条路径，它过了不代表没事）。出错的 ERROR 日志自带 row_mvcc/index_mvcc，翻出来能看出索引 key 和行 key 各自的 MVCC，先定位是索引指错行还是副本数据旧。之前有个类似的，最后确认是 ingest 建索引的 bug，升 patch 解决的，可以对照。
重新analyze table试试，或者重启有问题的tidb_server节点
把有问题的tidb节点完整日志拿出来看看
这个还挺奇怪，65和97 是a和A的ASCII值，66和98呢？
也确定下两个节点的执行计划是否是一致的。
只有这个值有问题
这个报错不是解析数字挂了，是回表后对索引值和行值做一致性校验，发现这一行两边对不上，等于索引里存的东西和表里的不一样。所以 analyze 和重启只是把窗口挪一下，根不在这，重新 analyze 之后大概率还会再冒出来。
只有某个值报、还正好撞上 65 这种 ASCII，我第一反应是这一列的类型或者字符集改过、索引里的表示没跟着变，或者这个索引用的是表达式、前缀这类特殊索引；从 MySQL 迁过来、用 lightning 导过数据的表也容易留这种残渣。
可以先 ADMIN RECOVER INDEX 按表把索引数据重建一遍，会占资源，大表挑低峰跑；要是反过来多了脏索引条目，就用 ADMIN CLEANUP INDEX，两个别混着用，语法看 ADMIN 。动手前把那个报错节点的 ERROR 日志留一份，里面的 index handle 和 kv 值能直接看出是索引错还是行错，贴上来我跟你一起看。
表和索引树，类型不对了，要重建索引吧
