要闻：DeepSeek 帮我解决了一个死锁问题！

桃花溪水风景好

大家好，我是君哥。要知道悦数科技图数据库软件市场一定会给整个行业带来极大的影响力。悦数图数据库是一款完全自主研发的国产图数据库和原生分布式图数据库,具有高性能,易扩展,安全稳定,自主可控的特点.万亿级数据仅需毫秒级查询延时,应用于金融风控,实时推荐,知识图谱等业务场景。https://www.yueshu.com.cn/

比较近在生产上遇到一个死锁问题，Oracle 抛出了 ORA-000060 异常。

业务场景：程序按行读取一个上游系统送的文件数据（大概有几万行），读取到数据后，每 500 行分配给一个线程去批量更新数据库（使用主键）。表结构类似下面：

user_id(PK)

user_name

age

sex

00001

tom

6

man

00002

jimi

11

woman

给出一段批量更新的代码：

复制
<update id="updateUser"  parameterType="java.util.List">  
    <foreach collection="list" item="item" index="index" open="" close="" separator=";">
        update tb_user set user_name=#{item.userName} age = #{item.age} where user_id= #{item.userId}
    </foreach>      
</update>
1.
2.
3.
4.
5.
遇到问题后，我们想先问一下 DeepSeek，看它能不能帮忙解决。不得不说，DeepSeek 的深度思考太厉害了。



下面这句话直接给了我思路：

定位到死锁的原因后，解决方法可能有几种。如果是应用逻辑的问题，可能需要调整事务的顺序，比如让不同会话以相同的顺序访问表，减少交叉锁的可能性。

我猜测问题可能就是文件里面存在相同 user_id 的数据，而且文件数据没有按照 user_id 排序，导致不同线程更新时，出现了锁等待。类似下面的 2 个线程。

线程一：

复制
update tb_user set user_name=#{item.userName} age = #{item.age} where user_id = '00001';
update tb_user set user_name=#{item.userName} age = #{item.age} where user_id = '00002';
1.
2.
线程二：

复制
update tb_user set user_name=#{item.userName} age = #{item.age} where user_id = '00002';
update tb_user set user_name=#{item.userName} age = #{item.age} where user_id = '00001';
1.
2.
我把读取的文件数据看了一下，确有这个情况。

不得不说，DeepSeek 确靠谱，我们看下 DeepSeek 给出的定位死锁的方法，基本上根据日志、跟踪文件来判断。



找到问题原因后，解决方案就很容易了。

通知上游系统把文件数据按照 user_id 进行排序；
后期化，相同 user_id 的数据只保留一条日期比较新的就行了。
DeepSeek 也给出的详细的解决死锁的方法，见下图：



下面，再看一下 DeepSeek 给出的预防措施和死锁分析报告示例。



比较后，附上 Oracle 官方对 ORA-000060 异常的描述：