Transaction中SQL的顺序引起的死锁

因为项目的数据更新频率很高，导致经常出现死锁的问题。感觉以下遇到的一种情况比较典型，也比较tricky，计之。

问题描述：

如以下两条非常简单的sql语句，它们共同组成了一个transaction，那么在多线程高频率执行时就会引起死锁问题（当然这里要考虑锁的级别问题，一般多类似这种系统都会选择行锁，那么以下引起死锁的条件是两条语句都对同一行操作）：

select <column1> from <table> where <column2> = ? 

update <table> set <column1> = %d where <column2> = '%s'

问题分析：

select语句需要“shared lock”，因而多个线程可以同时进入，而update需要“exclusive lock”，当两个线程同时执行了select语句，而获得了“shared lock”，而他们在接下来执行update语句时，都需要获得“exclusive lock”而产生竞争，导致死锁。

解决方案1:

互换他们的顺序，这样，在第一次执行update语句时，他们会竞争"exclusive lock"而引起没有得到“exclusive lock”的线程等待：

1, update <table> set <column2> = <column2> + <some value> where <column1> = '%s' 

2. select <column1> from <table> where <column2> = ? 

3. <column1> - <some value> to get the old <column1> value.

解决方案2：

采用“hold lock”方式，即在所有操作之前做一个dummy的update操作，这样可以保证在进transaction之前需要先获得一个“exclusive lock”