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

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


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

Error 8133

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

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

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

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

1 个赞

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

这个问题有解决方案么

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

admin cleanup index [table_name][index_name];

1 个赞

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

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

sql脚本:

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

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

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