【 TiDB 使用环境】生产环境
【 TiDB 版本】 5.4.2
【过程】queueok 这张表的isdelete 字段是int类型，并且只有三个值（0,1，null），
直接count 表数据得到是813602244，分别按isdelete 等值查询得到的结果是654550915，332686701，96173
这三个值结果加起来与比count总数多一亿多数据
【解决】将表重新dumpling 导入导出，问题解决，count到的数据是813602244，分别按isdelete 等值查询三个值结果加起来的值与count 总数是一样的
【中间出现的问题】
queueok 表中queueid 是主键，导入的时候报主键冲突，根据queueid grep sql 文件，发现存在相同的主键值，疑问，为啥设置了主键，数据库根据主键查询只有一条数据，dumpling 出来的文件却有两条主键id的记录
你这是表和索引不一致的问题吧，一般这种情况都是触发了bug
这个表是聚簇索引还是非聚簇索引？
表太大，总不能每次都dumpling解决，有啥办法避免呢
你这是表和索引不一致的问题吧，一般这种情况都是触发了bug
还有这个bug？
主键是 varchar 的时候，dumpling 不是根据主键来确定切割范围，而应该是 _tidb_rowid。那么原始表的数据是不是本身就有重复的两条主键记录？
你要不换成聚簇索引，读写速度更快，也不存在主键索引问题
这个表用 Lightning local 模式导入或者 tispark 回写功能回写过么？
这张表在mysql源端是分库分表的，通过otter 同步到tidb 汇总。
lightning local 需要该表三倍的空闲空间，这套磁盘空间没那么多，只能通过mysql < **.sql 的方式导入数据
mysql < **.sql 是文件导入吧，文件导入可以两边表类型不一样，要不你改成聚簇表
我试试
您好
这个问题一般是：
之前导入的时候主键上有重复数据，然后通过 lightning 非 sql backend 导入后，导致一个主键索引 key 对应 两条或多条真实数据导致的。
你查询的时候是实际 count 的是主键索引，dumpling 导出的时候是全表扫，取的是真实数据。所以会造成此现象。
1 个赞
这个问题很诡异。
1.上面这里的执行过程，你这边能否把它的explain analyze 执行过程都贴出来？我们一起分析分析
2.TiDB里的这张表它的数据是怎么写进去的呢？是通过DM同步，还是lightning 工具，还是业务直接insert ？
这个和mysql的应该不一样的吧