【 TiDB 使用环境】生产环境
【 TiDB 版本】v5.4.2
【复现路径】jdbc 批量执行 replace
【遇到的问题：问题现象及影响】 代码中手动提交事务，然后批量执行了一批 replace into 语句，50条。插入特别慢，看Dashboard，该段时间replace大量增长，后续改为一条一条插入，明显好转。我想了解一下这其中是什么问题导致的？
【资源配置】
【附件：截图/日志/监控】
【语句大概格式：replace into table_custom_info (…) values ( … ) 】
50条还好吧，中间有其他事务阻塞不
应该是有其他事务阻塞，在阻塞
这个可以在哪里查看到吗
50条数据也不多啊。表有多大?
把慢的执行计划捞出来看看。里面的信息可以帮助确定是哪里慢了。
tidb数据量很少可能1w不到
我看了，应该不是这个的原因
我觉得可能是和tidb的锁机制相关？因为我开启一个事务批量执行一批replace into 的SQL，而后又来了一个事务执行另一批replace into 的SQL，但是他们之间可能会修改同一条数据，导致后来的事务被阻塞，以此类推导致QPS中的replace into 请求居高不下，同时事务执行缓慢？
50条数据replace，正常很快的，是不是有其他事务占用了资源
正常情况下是很快的，我觉得应该是有其他事务占用了资源。因为他不是只执行一批，代码逻辑是每50条就处理一批，从业务库同步数据。
多线程并行执行且数据没有排序取值吗?
对，数据排序取值的，是按照业务库的自增主键依次录入，但是在写入时，把主键变成了雪花id。
感觉你50条是放在同一个事务
然后又有多线程再跑 是不是有锁
会不会与索引有关
