select * from {table} 本身就没有保证结果集稳定的语意。
不同的数据库有不同的实现方式，有的数据库因为它扫数的方式不同，处理结果集合的方式不同，有的可以天然保证有序，有的则不能。
比如：TiDB 里扫的数据在不同 Region 中，不同 Region 在不同 TiKV 中，扫的时候有时候先到 TIDB 有时候后到，这是无法保证的，应该算作是用问题。
建议如： ShawnYan 指出的那样，加 Order by 解决。
执行过了，也是没有效果
对的，没错，是非主键查询就有问题
没有可以排序的字段。。。。
https://docs.pingcap.com/zh/tidb/stable/sql-statement-admin-check-table-index#admin-check-tableindex
admin check一下那个表，看看有没有问题，我看你也找到了21年的那个帖子，那个帖子里面我看也没有最终回复，另外，楼上的两位大佬也说了一种可能性，你这个查询的时候，有没有加limit，工具有没有加limit，找一个字段，比如说item_id，查询的时候，加order by，这也是一种可能性。
哦哦，不对，我给看成 本该是 2 条数据，但是要求结果集合有序 的问题了，sorry。
问题应该是，delivery_id=4025931 却出现了 2351687？ admin check table 结果如何？
看着像数据索引不一致的问题， admin check table 结果如何？
哦哦，这个慢正常
，等结果吧
我这个是大范围的重复，不是零星的几条数据
看起来有点像数据和索引不一致的问题。
如果是的话曾经由这两个 pr 修复过
https://github.com/pingcap/tispark/pull/2156
https://github.com/pingcap/tispark/pull/2101
建议使用 tispark 2.4.3 看是否能够解决该问题
是个bug吗
看下执行计划走的那个索引，强制走另外的索引试试结果对不对；
好的，
我这边的tispark的版本是2.4.1，tidb的版本是5.3.0
tispark写入tidb的代码是：
df.write.
format(“tidb”).
option(“tidb.addr”, “xxx”).
option(“tidb.port”, “4000”).
option(“tidb.user”, “xxx”).
option(“tidb.password”, “xxx”).
option(“database”, “bdata”).
option(“table”,tblName).
option(“replace”,true).
option(“isolationLevel”,“NONE”).
option(JDBCOptions.JDBC_BATCH_INSERT_SIZE,1000).
mode(“append”).
save()
表总的数据量是千万级别，每次执行写入的条数大约是几千条，包含大量的update的记录
我这里换成了tispark换成了2.4.3也是一样的错误
data inconsistency in table: erp_sdb_wms_delivery_items, index: ind_number_delivery, index-count:4 != record-count:3
对不上是否应该试一下小黑大佬说的 admin cleanup 命令修复一下？