数据库在进行insert,update,delete这些更新操作的时候为了保证数据一致性都会使用排他锁。
一个事务里进行update操作,在事务结束之前(commit or rollback)排他锁不会被释放。因此在一个事务里update多条数据的时候执行顺序就尤为重要,两个并发事务中更新操作的执行顺序不同就有可能产生死锁:(x, y分别表示一行数据)
transaction A { transaction B {
getXLock(); getYLock();
update x; update y;
getYLock(); getXLock();
update y; update x;
} finally { } finally {
releaseXLock(); releaseYLock();
releaseYLock(); releaseXLock();
} }
另外,如果执行的update操作不在事务里,但一个update操作更新了多行数据(ex: update .. set .. where id > 1),在大并发的情况下也会有死锁的风险,原因仍然是与更新数据行的顺序有关。因此还是推荐更新操作最好以主键作为条件最为严谨,否则就需要在程序中先对更新的数据进行排序再进行批量更新(ex: update .. set .. where id in (1, 2, 3, 4..))。
当然如果是读写锁,要考虑读写的频率。
一个事务里进行update操作,在事务结束之前(commit or rollback)排他锁不会被释放。因此在一个事务里update多条数据的时候执行顺序就尤为重要,两个并发事务中更新操作的执行顺序不同就有可能产生死锁:(x, y分别表示一行数据)
transaction A { transaction B {
getXLock(); getYLock();
update x; update y;
getYLock(); getXLock();
update y; update x;
} finally { } finally {
releaseXLock(); releaseYLock();
releaseYLock(); releaseXLock();
} }
另外,如果执行的update操作不在事务里,但一个update操作更新了多行数据(ex: update .. set .. where id > 1),在大并发的情况下也会有死锁的风险,原因仍然是与更新数据行的顺序有关。因此还是推荐更新操作最好以主键作为条件最为严谨,否则就需要在程序中先对更新的数据进行排序再进行批量更新(ex: update .. set .. where id in (1, 2, 3, 4..))。
当然如果是读写锁,要考虑读写的频率。