MySQL悲观锁、乐观锁性能对比：报错
都说在高并发的时候MySQL乐观锁性能比悲观锁好很多，为什么我遇到的情况恰恰相反？ 我做了一个抢购商品的网站，一开始（不使用Redis等缓存的情况下）使用MySQL悲观锁，性能不是很好，后来改为乐观锁，通过版本号version来保证数据一致性，然后通过多线程来模拟高并发请求的情况，发现在使用乐观锁的情况下性能比悲观锁差了太多，原因是使用乐观锁的情况下，当一个线程尝试去更新一条MySQL记录的时候，不巧发现版本号（version）改变了，也就是说有其他的线程抢先一步更改了这条记录，为了保证数据一致性，那么当前线程的更新操作将失败，此时将重新发起更新操作。这样的“更新失败”情况大量发生，导致本来一次更新操作就可以完成的事情需要重复多次甚至十几次才能完成，最终导致系统性能急剧下降反而不如悲观锁性能。请问各位大神这种情况有什么更好的解决方案？
写回答
-
可以现在本地来保证数据的顺序访问，避免多个线程争夺同一条数据######但是在高并发的情况下，请求都是来个成千上万的不同客户端，如何在本地保证按顺序访问？而且悲观锁的本质实际上就是让多个不同的请求按顺序访问吧！######我的意思是先预加载数据库数据到本地，然后再做加锁或者乐观锁，因为用字段来做乐观锁在数据库还是用的行锁来保证的吧######回复 @Milk丿小庄 : java内部的cas是用的cpu本身支持的功能做的，而你用mysql的字段来做，当然效率低了######嗯 这样倒是可以，相当于缓存了嘛。我其实就是想知道为啥乐观锁和悲观锁的性能和书上、网上讲的都不一样 哈哈哈
2020-06-08 10:47:56赞同 展开评论 打赏
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
