【 TiDB 使用环境】生产环境
【 TiDB 版本】V5.4.2
【遇到的问题】
count 统计数据不准，
queueok 这张表的isdelete 字段是int类型，并且只有三个值（0,1，null），
直接count 表数据得到是813602244，分别按isdelete 等值查询得到的结果是654550915，332686701，96173
这三个值结果加起来与比count总数多一亿多数据
isdelete 上面有索引？如果是的话执行一下 admin check table quequok;
isdelete 上没有索引，我执行check table的时候报错了
mysql> admin check table queueok;
ERROR 8003 (HY000): queueok err:[admin:8223]index:&admin.RecordData{Handle:1152921504804366654, Values:types.Datum{types.Datum{k:0x5, decimal:0x0, length:0x0, i:0, collation:“utf8mb4_bin”, b:uint8{0x51, 0x4f, 0x32, 0x30, 0x32, 0x30, 0x30, 0x38, 0x32, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x37, 0x39, 0x35, 0x35, 0x34, 0x34, 0x31, 0x35}, x:interface {}(nil)}}} != record:&admin.RecordData{Handle:28308, Values:types.Datum{types.Datum{k:0x5, decimal:0x0, length:0x0, i:0, co
找官方吧，这样的输出 asktug 不能给解决方案兜底
还有这现象。。。
8003 ADMIN CHECK TABLE 命令在遇到行数据跟索引不一致的时候返回该错误，在检查表中数据是否有损坏时常出现
你这个表上有其他索引吗？
这个问题有意思，EXPLAIN ANALYZE看一下两种统计方式的执行计划？
额，这个表上数据和索引都不一致了，能全部重建索引吗，关键重建了后面问题应该还是会重新出现
估计得找官方修复了
https://docs.pingcap.com/zh/tidb/v6.5/troubleshoot-data-inconsistency-errors#error-8003
dumpling备份这个表重新导入吧
重新dumpling导入导出是可以，总数跟定值条件查询的结果能对得上
dumpling不导索引，索引是重建的肯定没问题
你这个表是通过tidb-lightning的物理导入方式导入的么？你试一下只统计最近一个月的，看是不是一样的
应该是索引有问题了，你根据isdelete查询的时候加hint全表查询试试结果。
我之前遇到过一次，重建索引就好了。
在什么场景下遇到的呢？分享下复现场景。
这个还真不好复现。能复现就光明正大的提bug了 
只要通过二级索引扫描，都会有问题