比較常見的死鎖場景，並發批量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
如此，就避免了死鎖的發生。