好的 OK
嗨，这个问题测试出来了吗，我们现在稳定复现，就是一个表有primary 主键索引和一个普通索引，然后我们根据普通索引的字段取更新时就会有这个问题了
这个是bug吗，如果是怎么避免呢
@Hacker_IslRgOns 不好意思， 问一下，咱们当前使用的方式是：1.把外部一个表分拆为多个application来写入。 能问一下，可以先不要拆分成多 application 来写入嘛（咱们这个问题，我们内部看了一下，多 application 的方式，和目前的一些设计有些兼容问题，后续会修改，但动作可能有点大，需要点时间）
目前多 application 的方式，可能不太好绕过，咱们这边能不能改成 单 application 的方式
是的，是拆分为多个application来写入的，其中还开启了replace=true，有重复则替换，目前来看，因为数据量有点大，需要拆分，不拆分的话很难跑下来，但是至少我们知道是这个原因引起的了，我们就能不拆就不拆，实在要拆，出现问题我们还是手动修复
另外想问下，如果是一个application批量写入写完了，后续又有一个批量修改操作，是否也会有这个问题，我们本来打算用tidb来做更新，但是现在来看有这样的问题
这个问题，我们会修复的，不过时间需要看这个工程量有多大，现在还无法确定
1、上面说的 一个结束后，另一个再操作，应该不会有问题的（咱们这次的问题，是当初的设计和 多 application 有所不兼容导致）
2、能否告诉一下，咱们的业务需求是什么？是否可以直接用 tidb-server（咱们好像只是 几百万的表，按道理说，不算太大，想了解一下，是否可以 用 tidb-server）
几百万的表是小表，几亿的表很多，使用tidb-server的意思是直接用jdbc?
对的，只是好奇问一下，主要不知道，咱们的具体环境是啥
就是有一批数据(大部分表是千万和亿级别)通过tispark写入tidb，之后会有多次的更新操作来修改,百万千万的更新，用jdbc不会吧tidb搞挂吗
哦哦，好的，tidb-server 在这大数据量上处理不如 tispark。这个问题，我们已经提升优先级了，有新进展，我再在这里同步吧
好的收到，谢谢谢谢
客气了，我们会尽快改进相关功能
1 个赞
请问这个问题解决了吗，我目前也遇到了，tidb的版本是5.3，查询出多条主键相同的记录
索引数据与表数据不一致，是bug