ISAM/MyISAM および HEAP テーブルのテーブルロック、BDB テーブルのページレベルロック、InnoDB テーブルの行レベルロックのみが、MySQL で現在サポートされています。 See 項5.3.1. 「MySQL のテーブルロック方法」。 INSERT ステートメント間に競合がない場合（レコードまたはデータの削除による空き領域を埋めるのではなく、テーブルファイル末尾に追加する場合はいつでも）、MyISAM テーブルでは INSERT と SELECT をロックなしで自由に組み合わせることができます。

バージョン 3.23.33 からは、システムにおけるテーブルロックの競合を Table_locks_waited および Table_locks_immediate 環境変数を確認して分析できるようになりました。

テーブル型を行レベルロックと共に使用するかどうかを決定するには、アプリケーションの処理内容とデータの選択/更新パターンを確認する必要があります。

行ロックの利点:

行ロックの欠点:

以下の場合、ページレベル/行レベルロックよりもテーブルロックの方が適しています。

行レベル/ページレベルロック以外の他のオプション:

バージョン管理（MySQL では並列 INSERT に使用）。多数の読み取りと同時に単一の書き込みが可能です。つまり、データベース/テーブルでは、ユーザがアクセスを開始した時期に基づき、異なるビューが同じデータに関してサポートされます。これはタイムトラベルにたとえることも、書き込み時コピー、コピーオンデマンドと呼ぶこともできます。

多くの場合、コピーオンデマンドは、ページレベルまたは行レベルのロックよりもはるかに優れています。ただし、最悪の場合、通常のロックよりもはるかに大量のメモリを消費します。

行レベルロックの代わりに、アプリケーションレベルロック（MySQL での get_lock/release_lock と同様）を使用することができます。言うまでもなく、このロックが役立つのは正常に動作するアプリケーションに限られます。

多くの場合、アプリケーションに最適なロックタイプは経験に基づき推測できます。しかし、指定されたロックタイプが別のロックタイプよりも好ましいと判断するのは一般的に極めて困難です。すべてがアプリケーションに依存しており、アプリケーションにおける異なった部分には異なったロックタイプが必要とされるからです。

MySQL でのロックに関するヒントを以下に示します。

多くの Web アプリケーションでは、多くの選択、一部の削除、更新が主としてキーで実行され、挿入が特定のテーブルに対して実行されます。 MySQL の基本設定は、上記に適した状態になっています。

同一テーブル内のレコードを大量に確認する必要のある更新と選択を併用しない場合、同時ユーザは問題になりません。

同一テーブルで挿入と削除を併用する場合、INSERT DELAYED が役立つことがあります。

また、LOCK TABLES を使用して処理速度を向上させることもできます（単一ロックでの多数の更新は、ロックなしの更新よりもはるかに高速です）。複数のテーブルに分割するのも有効な対策です。

MySQL でのテーブルロックに処理速度の問題がある場合、テーブルの一部をInnoDB または BDB テーブルに変換して解決できることもあります。 See 項7.5. 「InnoDB テーブル」。 See 項7.6. 「BDB または BerkeleyDB テーブル」。

このマニュアルの最適化に関するセクションでは、アプリケーションの調整方法の多種多様な局面について取り上げています。 See 項5.2.13. 「その他の最適化のヒント」。