tidb5.0.3
在tidb上做活动商品抢购，大并发update时，造成大量的update走主键的慢查询。
1.tidb不能做这种操作吗？
2.怎么避免这样的慢查询产生？临时调整为乐观锁？
3.有没有相应这种形式的案例参考啊？
!
!
你需要的场景是对 某一行数据 并发更新么？
每秒 N 行 数据，会有 N 次更新？是这样的么？
我们这边秒杀是放到redis的，没有放到数据库~
这个问题，不是应该让需求从业务，架构从技术，两个角度给你帮助么？
mysql 一样会有并发问题（资源争抢很常见，总会有失败的）
什么都没改变的情况下，tidb这块因为慢查询，这个功能已经无法使用了。
迁移到mysql，一切正常无影响，所以不明白区别在哪里，是乐观悲观锁影响的？
1）没有大一统的数据库，每个数据库都有其擅长的使用场景；
2）TiDB是分布式数据库，因其分布式的特性，相当于单机版本的mysql在锁的开销要重一些，当然优点很多，单机版的痛点就是其优点；
3）这种秒杀的造成热点场景，通用做法是排队和合并请求，以此减少热点资源争用，现在你能用mysql抗住，说明还没有到秒杀的场景；
1.对，没有银弹
2.有预料锁会比mysql开销大
3.mysql能抗住，确实目前还没有达到那个量级，但是我不明白，其实没有特别大规模的秒杀，为什么tidb会受影响这么大呢？
这个说来就话长了，这就需要了解分布式的特性，多个组件协同工作，之间网络请求和交互就比单机多很多，再加上主机之间的性能差异导致木桶理论，影响的因素多了去。建议多了解下。
1 个赞
后面怎么解决这个场景的呢，tidb有做一些优化没，例如隔离级别，锁模式等的修改。
1 个赞
后来这部分放到mysql中了
1 个赞
秒杀这种，一般是先在内存中进行处理，然后统一更新数据库，减少对数据库的压力，不能没来一个请求就更新数据库，这样没有太多的意义。
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。