执行计划里面的prepare: 313.4ms, 是不是有可能因为间隙锁的原因？
你时一条语句嘛，单条差不多100ms左右。
单条sql，300ms +
这个确实是一个思路，并发的话存在资源争用
兄弟有什么好的优化建议吗
- 业务上是不是进行一些处理，减少类似的并发情况，因为看需求基本上是批量更新
- 如果业务上处理比较麻烦，是否能接受 replace into 这种先删后插，affected_rows = 2 的，可能减少这种场景，因为需求批量更新，理论上冲突不会太多
该主题在最后一个回复创建后60天后自动关闭。不再允许新的回复。