デッドロックの原因とされる「逆順に処理が実行される」というのがイメージできません。
トランザクション１がテーブルA→テーブルBの順で更新を行い、
トランザクション２がテーブルB→テーブルAの順で更新を行うときは、逆順になっているというのが理解できます。

同じ処理内容の複数のトランザクションが同じテーブルの同じ行に対して処理するときに逆順になることがあるのでしょうか？(H17 午後１ 問４の問題)
また。アクセスする順序を定義してトランザクションがその順番通りに処理をすることで回避できるということですが、仮に商品番号順に処理をしても、同じ商品番号を更新するトランザクションが複数あったらデッドロックが発生するのではないでしょうか？

よろしくお願いいたします。

該当の問題をやってないので本文から想像しつつですが...
ネットショッピングとかでカートにモノを突っ込んだ状態のような
何らかの注文処理の明細データをイメージしてください（S01～S04は商品番号）


Aさんの注文      Bさんの注文
------------------------------------
S01   5個        S04   3個
S03  10個        S02   6個
S04  15個        S03   9個

在庫テーブル(☆更新対象☆)
------------------------------------
S01             1000個
S02             1000個
S03             1000個
S04             1000個


注文を確定したら在庫テーブルから在庫数が減っていくとします。
仮にAさんとBさんがほぼ同時に注文を確定したとして

１．注文データが上から順に処理される場合（カートに突っ込んだ順とか）

  Aさんの注文            Bさんの注文
  ------------------------------------
  S01   5個(更新)        S04   3個(更新)
          ↓                  ↓
  S03  10個(更新)        S02   6個(更新)
          ↓                  ↓
  S04  15個(Bさん待ち)   S03   9個（Aさん待ち）  ＜デッドロック



２．商品番号順に処理される場合

  Aさんの注文            Bさんの注文
  ------------------------------------
  S01   5個(更新)       S02   3個(更新)
          ↓                  ↓
  S03  10個(更新)       S03   6個（Aさん待ち）
          ↓                  ↓
  S04  15個(更新)             ↓
          ↓                  ↓
      コミット                ↓
                         S03   6個（更新）
                              ↓
                         S04   9個（更新）
                              ↓
                          コミット


商品番号を気にせず上から順に更新される場合だと
Aさんが処理しようとした商品は既にBさんの処理で更新されていて
Bさんが処理しようとした商品は既にAさんの処理で更新されてしまっており
デッドロックが起きてしまいます。

一方で商品番号順にすることで
在庫テーブルへの更新順が入れ替わることがなくなりデッドロックが起きません。
（※商品番号順なので、S04の処理が終わった後に、Bさんの注文で
    処理したS02の商品が更新対象として回ってくることがない）

上記例ではAさんの方が若干早かったとして書いてますが
Bさんの方が早かった場合でも同様ですし、同時に処理されるユーザーが
他に複数発生しても在庫テーブルでデッドロックがかかることはありません。

あれーーー
プレビューで何度も確認したのに矢印がズレてしまった
なんてことかしら

トランザクションの中の処理で参照される商品番号が逆順になるということなんですよね。
処理の順番が逆になるとずっと勘違いしていました。

商品番号順にロックすることで、別のトランザクションは解放待ちになり、デッドロックを回避できるのも納得することができました。

ｍｋｋさんありがとうございます。