大きなテーブルで、テーブルレベルのロックが行レベルのロックよりも優れているのはなぜですか？
MySQLマニュアル によると：
大きなテーブルの場合、テーブルロックは行ロックよりも優れています。
どうしてこれなの？大きなテーブルをロックすると、より多くのデータがロックされるため、行レベルのロックの方が良いと思います。
（編集前）から リンク
より多くのロックを取得する必要があるため、テーブルの大部分で使用される場合、ページレベルまたはテーブルレベルのロックよりも低速
1行か2行しかヒットしない場合は、行レベルのロックを使用してください。コードが多数の行または不明な行にヒットする場合は、テーブルロックを使用してください。
行ロックは、テーブルまたはページレベルのロックよりも多くのメモリを必要とします。
より多くのリソースを消費する行ロックを使用して、さらに多くのロックを取得する必要がある
から http://www.devshed.com/c/a/MySQL/MySQL-Optimization-part-2/
行レベルのロックの利点：
- 多くのスレッドで異なる行にアクセスするときのロック競合の減少。
- ロールバックの変更が少なくなります。
- 単一の行を長時間ロックすることを可能にします。
行レベルのロックの欠点：
- ページレベルまたはテーブルレベルのロックよりも多くのメモリを使用します。
- より多くのロックを取得する必要があるため、テーブルの大部分で使用すると、ページレベルまたはテーブルレベルのロックよりも遅くなります。
- データの大部分に対してGROUP BY操作を頻繁に実行する場合、またはテーブル全体をスキャンする必要がある場合は、他のロックよりも明らかに悪いです。
- より高いレベルのロックを使用すると、ロックオーバーヘッドが行レベルのロックよりも少ないため、アプリケーションを調整するために異なるタイプのロックをより簡単にサポートすることもできます。
次の場合、テーブルロックはページレベルまたは行レベルのロックよりも優れています。
- テーブルのほとんどのステートメントは読み取りです。
- 厳密なキーの読み取りと更新。1つのキーの読み取りでフェッチできる行を更新または削除します：
UPDATE tbl_name SET column=value WHERE unique_key_col=key_value;DELETE FROM tbl_name WHERE unique_key_col=key_value; - SELECTは、同時INSERTステートメントと組み合わされ、UPDATEステートメントとDELETEステートメントはほとんどありません。
- ライターなしでのテーブル全体に対する多くのスキャンまたはGROUP BY操作。
あ 行 テーブルレベルのロックは、大きなデータ変更が行われている大きなテーブルに適しています。これにより、システムは、膨大な数のロック（各行に1つ）を処理する必要がなく、テーブルの単一のロックと競合します。
RDBMSは自動的にロックレベルを内部的にエスカレートします。
テーブルのロックにより、多くのセッションが同時にテーブルから読み取ることができます
MySQLは非常に高いロック速度を実現するために、テーブルロックを使用します。
「行レベルのロックの方が良いと思います」[ロックするデータが少ない]。
このページでは、最初の「より良い」の定義が不十分です。良いということは「速い」という意味です。
ロックの競合のため、行レベルのロックは（一般的に）速くなることはできません。大きな結果セットの各行をロックすると、別の大きな結果セットクエリとの競合やロールバックが実際に発生する可能性があります。
一般に、大量のデータをロックする必要がある場合、大きなテーブルでの1つのロックは、行レベルのロックやページロックの束全体よりも安価です。