sql查询出现数据索引一致性报错

[monlor]

Bug 反馈
清晰准确地描述您发现的问题，提供任何可能复现问题的步骤有助于研发同学及时处理问题
【 TiDB 版本】v6.2.0
【 Bug 的影响】
查询的数据不在筛选条件范围内
【可能的问题复现步骤】

【看到的非预期行为】
昨天同样的sql出现筛选条件不生效的情况，比如dim_code=x，结果里出现dim_code=y的情况。今天是直接报错了，错误信息如下：
8133 - data inconsistency in table: SYS_PERMISSION_DIM_VALUE, index: HAUTH_PERMISSION_DIM_VALUE_U1, index-count:184 != record-count:183
【期望看到的行为】

【相关组件及具体版本】

【其他背景信息或者截图】
如集群拓扑，系统和内核版本，应用 app 信息等；如果问题跟 SQL 有关，请提供 SQL 语句和相关表的 Schema 信息；如果节点日志存在关键报错，请提供相关节点的日志内容或文件；如果一些业务敏感信息不便提供，请留下联系方式，我们与您私下沟通。
查询SQL语句:

select * from SYS_PERMISSION_DIM_value where dim_code = 'WDKJ_ORG' and employee_group_id = 1509781370026692618 order by dim_value_code, is_editable

[tidb狂热爱好者]

不清楚你想表达什么 是sql结果和你预期不一致？

[Kongdom]

Error 8133

ERROR 8133 (HY000): data inconsistency in table: t, index: k2, index-count:1 != record-count:0

上述错误表明，对于表 t 中的 k2 索引，表中索引数量为 1，行记录的数量为 0，数量不一致。

[monlor]

对的，之前是查询出现不正确的结果，同样的sql，之前出现筛选条件不生效的情况（比如筛选employee_group_id=1，出现了employee_group_id=2的情况），现在是直接报错了

[qizheng]

当前 v6.2 集群是从之前哪个版本升级上来的吗，从 v6.0 开始，一致性检查的参数
tidb_enable_mutation_checker 是默认开启的，如果遇到 8133 报错会回滚 DML 语句

[monlor]

当前v6.2的集群不是升级上来的，但是用br恢复过之前集群的数据（之前的集群是从v5.x升级到v6.2的）。我查了下这个值是启用的。

[monlor]

这个问题有解决方案么

[qizheng]

那应该是 v5.x 版本存在的问题，BR 备份恢复时也不会检查数据不一致，之前版本存在一些 bug 会导致在某些情况下没有删除索引 key；上面报错提示索引数据数量要比记录数据数量多，可以先清理多余的索引数据，建议将 tidb_enable_mutation_checker 参数打开，避免再遇到这类问题

admin cleanup index [table_name][index_name];

[Kongdom]

先按照楼上老师的指导操作一下吧。

[monlor]

索引清理了，不报索引的错了，出现昨天的查询异常了，筛选条件控不住，结果如下：

sql脚本：

select * from SYS_PERMISSION_DIM_value where dim_code = 'WDKJ_ORG' and employee_group_id = 1509781370026692618 order by dim_value_code, is_editable;

[qizheng]

检查一下表上还有没有数据索引不一致的情况
https://docs.pingcap.com/zh/tidb/stable/sql-statement-admin-check-table-index#admin-check-tableindex

[Tank001]

上面老师好强 , 虽然没遇到, 也学习下