DBロックは、行、ページ、またはテーブルやインデックス全体に存在できます。トランザクションが進行中の場合、トランザクションによって保持されているロックがリソースを占有します。ロックのエスカレーションとは、システムが複数のロックをより高いレベルのロックに統合する（たとえば、複数の行ロックを1つのページに統合したり、複数のページをテーブル全体に統合したりする）ことで、通常、多数の細かいロックによって使用されているリソースを回復します。
これは自動的に行われますが、テーブルにフラグを設定して（オンラインブックの「ALTER TABLE」を参照）、その特定のテーブルのロックエスカレーションのポリシーを制御できます。特に、2つのプロセスが同じページに同時に別々の行を書き込む場合、SybaseとSQL Serverの古いバージョンでは、時期尚早または過度に熱心なロックのエスカレーションが問題でした。十分に前に戻ると（IIRC SQL Server 6.5）、SQL Serverには実際には行ロックがありませんでしたが、テーブルまたはページしかロックできませんでした。これが発生した場合、同じページ内のレコードの挿入間で競合が発生する可能性があります。新しい挿入が別のページに移動するように、テーブルにクラスター化インデックスを配置することがよくあります。
SQL Serverはロックエスカレーションメモリのオーバーヘッドを減らすのために、いくつかの細粒度の低レベルロックを粗粒度の高レベルロックに変換します。
- 行ロックは常にテーブルロックにエスカレートされます。
- ページロックもテーブルロックにエスカレートされます。
これは行ロックがページロックにエスカレートされるという神話であり、@ ConcernedOfTunbridgeWellsによって前述されたのと同じことは間違っています。
行の更新が非常に少ないテーブルの場合、SQLエンジンはそれらの行の行ロックまたはそれらのページのページロックを取得しようとします。行ロックがかかったとしましょう。ただし、行の更新によってしきい値が増加する場合（約5,000ロック）、複数の行ロックを取得する代わりに、単一のテーブルロックを取得します。したがって、これにより、複数の行ロックを解放して単一の表ロックを取得することでメモリのオーバーヘッドが削減されますが、同時実行性は向上します。同じことがページロックでも起こります。
ロックエスカレーションのしきい値は少なくとも5000ロックであり、いくつかの要因に依存します。ロックエスカレーションの詳細な説明は、MSDN BoLでここに記載されています： https://technet.Microsoft。 com/en-us/library/ms184286（v = sql.105）.aspx
ロックのエスカレーションとは、ロックをより制限的なモードに変換することを意味します。これはデータベースでよく見られます。クエリには、「共有」用にロックされたリソースがあり、更新を実行するためにそれを「排他的」にエスカレートする場合があります。