统计表行数,结果有问题。

一个表实际行数为1767,select count(1) 返回是3071



看一下执行计划

ADMIN CHECK table 表名执行下看看

检查 TiDB 的复制状态,确保主从节点之间的数据同步没有延迟

ADMIN CHECK table tb_xxx

8223 - data inconsistency in table: tb_xxx, index: PRIMARY, handle: 2356, index-values:“handle: 2356, values: [KindString 81EFAD65-FC94-493F-AD3E-1957DD2D4CE6 KindInt64 2356]” != record-values:“”
时间: 0.09s

只有一个主键的Non_unique | 0 索引

看执行计划,走的是索引?
看看索引有没有问题

这都已经报错有一致性问题了。根据现象看,走索引是3071条数据,走整表数据是1767数据,也证明是索引有问题。

这应该是索引和数据不一致了,重建下索引

1 个赞

count(*)呢 看看和count(1)一样吗


重建了下 主键索引,可以了。

也是那个导表后的问题

所以lightning物理导入模式,要注意看报错啊 :joy_cat:

我也遇到过一次,一般是什么场景会出现这种问题?主要就是数据导入么?

1 个赞

索引重建吧

学习了。感觉挺严重呀。count(1)跟行数不一样。。
以前oracle的时候不是使劲说count(1)比count(*)更加省时间吗。
lightning的backend='local’真的要注意,它跟oracle里面sqlldr的direct=true类似,会破坏索引,用完要重建索引。不重建的情况下,我感觉oracle的处理会好一些,它直接让索引invalid了。tidb是否可以学习一下,不要返回一个错误的结果,这样很不好。

哈哈哈,确实是,不过最后验证好像都差不多。估计数据库底层都给优化咯。

1 个赞

感谢你让我知道还有这么一种情况

1 个赞

oracle也没这个说法,或者说可能在20年前有。起码我从开始用oracle10g就没这个说法了