0

MS Sql（2008など）を使用して、ローカライズされた文字列を単一のデータテーブルに保存しています。ほとんどの文字列は短く、varchar(200) で表すことができますが、約 10% ははるかに長く、varchar(5000) のようなものが必要です。私の質問は、これを次のように 2 つのテーブルに分割すると、短い文字列を取得するときにパフォーマンス上の利点があるかどうかです。

CREATE TABLE ShortTextTable(ID bigint IDENTITY(1,1) NOT NULL, TextValue nvarchar(200))
CREATE TABLE LongTextTable(ID bigint IDENTITY(1,1) NOT NULL, TextValue nvarchar(4000))

対：

CREATE TABLE TextTable(ID bigint IDENTITY(1,1) NOT NULL, TextValue nvarchar(4000))

このデータが更新されることはめったにありません。私が本当に関心があるのは読み取りだけです。

4

4 に答える 4

3

場合によります。時期尚早の最適化である可能性があります。

列を小さくすると、ページあたりの行数が増えることは明らかですが、使用パターンによっては、提案している水平パーティションがあまり効率的ではない可能性があります。これは、両方の新しいテーブルから情報を取得するためです。読み取りの使用パターンと、テーブルがどのように結合されているかを確認する必要があると思います。

また、論理的に 1 つのスペースであるスペースを分割しているため、1 つのスペースとして管理できなくなります (つまり、両方の場所にインデックスを追加するなど)。

このように分割する前に、実際にボトルネックを確認し、提案された変更をプロファイルする必要があります。

確かではありませんが、列の長さに基づいてテーブルを文字通りパーティション化することは可能かもしれません (SQL Server のパーティション分割されたテーブル機能を使用)。繰り返しますが、これが役立つかどうかは、プロファイリングする必要があります.

于 2009-07-13T18:22:52.683 に答える
2

いいえ、本当の利益はありません。文字列サイズのインターリーブ、特に base don と int PK が原因のボトルネックを確認するには、非常に極端です。
一方で、このようなストレージ スキーマを使用する際の混乱は非常に明確であり、実際に存在します。まだ取得していない文字列の長さに基づいて、どのテーブルを参照するかを決定する必要があります。おそらく、試行錯誤 (1 つのテーブルを試してから、別のテーブルを試す) で探すことになるでしょう。これは、テーブル nvarchar ストレージ構造の問題よりもはるかに無駄です。

于 2009-07-13T18:27:57.200 に答える
1

なしまたは負のゲイン、

ストレージに関して: 可変長文字列は、文字数 + 長さ 2 バイトとして格納されます。したがって、データの長さは同じですが、2 番目のテーブルのインデックスとキーのオーバーヘッドが発生します。

賢明な処理：

  • 追加するテーブルを決定する
  • タイプミスを修正することは、それが間違ったテーブルにあることを意味します (前方ptrsなどを無視します)
  • 2 つのテーブルのキーの一意性を処理する (共通の親がある場合)

さて、もっと重要なのは、ローカリゼーションについて言及したのを見ましたが、nvarchar が必要ですか? 別の SO の質問: varchar と nvarchar のパフォーマンス

于 2009-07-13T19:24:25.867 に答える
1

SQL 2005 では、2008 では NVarChar(5000) を作成しないと思います。そのようなデータ型でページ サイズを超えると、その時点で NVarChar(Max) が機能します。nVarChar に数値 N を指定する場合、最大 4000 の制限があります。

その時点で、インラインに格納された値をページに読み取る場合と、ページを読み取って LOB ページへの 16 バイト ポインターを取得し、そこからデータを読み取る場合とでは、パフォーマンスに違いがあると思います。

于 2009-07-13T18:49:17.547 に答える