第 4 週目 ページ制限 8060 バイト_html/css_WEB-ITnose

おめでとうございます! SQL Server パフォーマンス チューニング トレーニング の最初の 1 か月を完了できるまで、あと数ページしか残されていません。今日は、次のページでいくつかの制限について説明し、なぜそれらが好きになるのか、なぜ嫌いになるのかについて説明します。

第 2 週で学んだように、データ ページのサイズは常に 8kb であり、そこに保存できるのは 8060 バイトのみです。レコード サイズは、1 ページに保存できるレコードの数を示します。 CHAR、INT、DATETIME などの固定長データ型を扱う場合、SQL Server にはレコード長が 8060 バイト (内部行オーバーヘッドの 7 バイトを含む) を超えてはいけないという制限があることがわかります。

テーブルの列が 8 未満の場合、(レコードごとに) 内部行オーバーヘッドを 7 バイト追加する必要があります。 8 列追加するごとに 1 バイトを追加します。たとえば、17 列の場合、9 バイトの内部行オーバーヘッド (7+1+1) が必要です。これより長いレコード サイズを作成しようとすると、CREATE TABLE ステートメントの実行時に SQL Server からエラー メッセージが返されます。次のテーブル定義を見てみましょう:

1 CREATE TABLE TooLargeTable12 (3    Column1 CHAR(5000),4    Column2 CHAR(3000),5    Column3 CHAR(54)6 )7 GO

ご覧のとおり、各レコードには 8061 バイト (5000+3000+54+7 バイト) が必要です。したがって、この場合、このテーブルを作成しようとすると、SQL Server は次のエラー メッセージを返します。

8 列を超えるテーブルを作成する場合は、SQL Server に必要な 8 バイトの行内部オーバーヘッドを含める必要があります。

すごいです

ここに別の不正なテーブル定義 (8000+53+8 バイト) があり、SQL Server はここでエラー メッセージを返します。

前のリンクでは、そのようなテーブルを作成すると SQL Server がエラー メッセージを返すため、ページ制限の良い面を示しました。ただし、ページ制限には厄介な側面もあります。SQL Server ではそのようなテーブルを作成できるため、INSERT ステートメントが成功する場合もあれば失敗する場合もあります。見てみましょう。

ここで直面する問題は、VARCHAR のような可変長データ型に関するものです。これらの列が独自のページに存在できない場合、SQL Server はそれらを別のページの行オフセットに移動します。これは 行オーバーフロー ページ と呼ばれます。 SQL Server は、行オーバーフロー ページへの 24 バイト長のポインターを元のページに残します。

他の列を組み合わせると、このポインターが 8060 バイトの制限を超える場合があります。次のテーブル定義を見てみましょう:

1 CREATE TABLE TooLargeTable22 (3    Column1 CHAR(1000) NOT NULL,   Column2 CHAR(1000) NOT NULL,4    Column3 CHAR(1000) NOT NULL,   Column4 CHAR(1000) NOT NULL,5    Column5 CHAR(1000) NOT NULL,   Column6 CHAR(1000) NOT NULL,6    Column7 CHAR(1000) NOT NULL,   Column8 CHAR(1000) NOT NULL,7    Column9 CHAR(53) NOT NULL8 )9 GO

ご覧のとおり、ここでは VARCHAR(3000) のデータ型を使用しています。ここで SQL Server が警告メッセージを表示することがわかります。この警告は、このテーブルを作成できるが、INSERT/UPDATE ステートメントの実行時に失敗する可能性があることを思い出させます...

テーブル内の次の挿入ステートメントは成功します:

1 CREATE TABLE TooLargeTable32 (3    Column1 CHAR(5000),4    Column2 CHAR(3000),5    Column3 CHAR(30),6    Column4 VARCHAR(3000)7 )8 GO

ここでのレコード サイズ長さは 8056 バイト (5000+3000+30+19+7 バイト) です。この場合、SQL Server はメイン データ ページの列 4 にデータを保存します。しかし、次の INSERT ステートメントを想像してください。

1 INSERT INTO TooLargeTable3 VALUES2 (3    REPLICATE('x', 5000),4    REPLICATE('x', 3000),5    REPLICATE('x', 30),6    REPLICATE('x', 19)7 )8 GO

先ほどの INSERT ステートメントでは、SQL Server は 4 番目の列のデータを行オーバーフロー ページ (行オーバーフロー ページ) に移動します。これは、これらの 3000 バイトをメイン領域に配置できないためです。データページ。これは、SQL Server が、データが見つかる別のページへの 24 バイトの長さのポインターを残すことを意味します。ただし、レコード サイズは 8061 バイト (5000+3000+30+24+7 バイト) になりました。

Duang、レコード長が 8060 バイトを超えているため、INSERT ステートメントが失敗しました。

これらは、データベース操作中に隠されるため、悪い制限ですが、上に示したようにテーブル スキーマを定義すると、良い面が見えてきます。考えてみてください、それは何ですか？

テーブル構造を設計するときは、操作について非常に慎重に考える必要があります。 SQL Server でページを処理する場合、実行後にのみ現れるこのような制限が数多く発生します。もちろん、SQL Server でエラー メッセージが表示されると、このテーブルを作成することはできなくなり、世界は基本的に平和になります。

注意を受けた場合、基本的に誰もが何も考えずに無視します。これは常に悪い方法です。これまで見てきたように、INSERT が実行時に失敗する可能性があり、問題が発生することが予想されるからです。このパフォーマンス チューニング トレーニングが要点をまとめたものであり、データ ページの内部構造を理解することがなぜ非常に重要であるかが理解できたと思います。

次のトレーニングでは、SQL Server のヒープ テーブルについてさらに詳しく説明し、ヒープ テーブルが良い場合 (設計) と悪い場合 (設計) がある理由を説明します。残り7日間、ぜひ楽しんでください！