数据库update死锁

比较常见的死锁场景,并发批量update时的一个场景:
update cross_marketing
set gmtModified = NOW(),
pageview = pageview+ #extpageview#
WHERE marketingId=#marketingId#

 

第一次调用时,marketingId传入值顺序: 1,3,5,12
第二次调用时,marketingId传入值顺序:1,2,5,3
 
每次update时,会锁行。(一次批量操作为一个事务)
那么第一次调用时,顺序锁行,当更新完3,准备更新5的时候,发现5已经被第二次调用锁行了,就等待。而此时的第二次调用刚好更新完5准备去拿3的锁,却发现被第一次调用占有,于是就出现死锁。
 
所以,我们要在批量更新,更新操作的时候,按照一个固定的顺序来排序,然后进行操作。
前面的例子,如果按照marketingId从小到大排序,就会变成:
第一次调用时,marketingId传入值顺序: 1,3,5,12
第二次调用时,marketingId传入值顺序:1,2,3,5
如此,就避免了死锁的发生。

posted on   每当变幻时  阅读(2400)  评论(2编辑  收藏  举报

编辑推荐:
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
阅读排行:
· 周边上新:园子的第一款马克杯温暖上架
· Open-Sora 2.0 重磅开源!
· .NET周刊【3月第1期 2025-03-02】
· 分享 3 个 .NET 开源的文件压缩处理库,助力快速实现文件压缩解压功能!
· [AI/GPT/综述] AI Agent的设计模式综述

导航

< 2025年3月 >
23 24 25 26 27 28 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5

统计

点击右上角即可分享
微信分享提示