デッドロックのロールバック対象

MySQL

(8)
https://dev.mysql.com/doc/refman/8.0/en/innodb-deadlock-detection.html

InnoDB tries to pick small transactions to roll back, where the size of a transaction is determined by the number of rows inserted, updated, or deleted

Oracle

(12cR1)
https://docs.oracle.com/cd/E57425_01/121/CNCPT/consist.htm#GUID-C1971E9B-849A-4634-9575-4F8FAD697750

文レベルのロールバックが発生するセッションはどちらになるかは不定

デッドロック状態になっているセッションのうちの一方のみが実際にデッドロック・エラーを受信しますが、
どちらのセッションもエラーになる可能性があります。

PostgreSQL

(12)
https://www.postgresql.jp/document/12/html/explicit-locking.html#LOCKING-DEADLOCKS

アボートされるトランザクションは不定

PostgreSQLでは、自動的にデッドロック状況を検知し、関係するトランザクションの一方をアボートすることにより、
この状況を解決し、もう一方のトランザクションの処理を完了させます
（どちらのトランザクションをアボートするかを正確に予期するのは難しく、これに依存すべきではありません）。

SQL Server

(2019)
https://docs.microsoft.com/ja-jp/sql/relational-databases/sql-server-transaction-locking-and-row-versioning-guide?view=sql-server-ver15#deadlocks

小さいトランザクションがロールバックされる

既定では、SQL Server データベースエンジンにより、
ロールバックに最もコストのかからないトランザクションを実行しているセッションがデッドロックの対象として選択されます。
また、ユーザーは、SET DEADLOCK_PRIORITY ステートメントを使用して、デッドロックが発生した場合のセッションの優先度を指定することもできます。
DEADLOCK_PRIORITY には、LOW、NORMAL、または HIGH を設定するか、あるいは -10 ～ 10 の範囲の整数値を設定することができます。