一个表实际行数为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数据,也证明是索引有问题。
这应该是索引和数据不一致了,重建下索引
count(*)呢 看看和count(1)一样吗
也是那个导表后的问题
所以lightning物理导入模式,要注意看报错啊
我也遇到过一次,一般是什么场景会出现这种问题?主要就是数据导入么?
索引重建吧
学习了。感觉挺严重呀。count(1)跟行数不一样。。
以前oracle的时候不是使劲说count(1)比count(*)更加省时间吗。
lightning的backend='local’真的要注意,它跟oracle里面sqlldr的direct=true类似,会破坏索引,用完要重建索引。不重建的情况下,我感觉oracle的处理会好一些,它直接让索引invalid了。tidb是否可以学习一下,不要返回一个错误的结果,这样很不好。
哈哈哈,确实是,不过最后验证好像都差不多。估计数据库底层都给优化咯。
感谢你让我知道还有这么一种情况
oracle也没这个说法,或者说可能在20年前有。起码我从开始用oracle10g就没这个说法了