4

最大速度のために最適化する必要があるデータベースを設計しています。

すべてのデータベース データは、入力データベース (編集中のデータ、主に Google マップのポリライン、マーカーなどを保持するもの) と呼ばれるものから一度生成されます。

そのため、データベースは編集の対象ではありませんが、ユーザーに結果をすばやく表示するために、できるだけ多くのデータを保持する必要があります (街中のルート、カスタム ポリラインなど)。

問題は、int よりも smallint のような小さいデータ型を選択すると、パフォーマンスが向上するか、またはパフォーマンスに影響するかということです。スペースはそれほど問題ではありません。いくつかの簡単な計算の後、データベースは 200 MB を超えず、100.000 行を超えるテーブルはありません (平均は約 5.000 になります)。

私がこれを尋ねているのは、インターネットでいくつかの記事を読み、小さなデータ型がパフォーマンスを向上させると言う人もいれば、追加の処理を行う必要があるためにパフォーマンスに影響を与えると言う人もいるからです。小規模なデータベースの場合、おそらく結果が目立たないことは承知していますが、より多くのクエリをトリガーする多くのリクエストが予想されるため、あらゆる点に関心があります。

ホスティング環境は、SQL Server 2008 R2 を搭載した Windows Server 2008 R2 になります。

編集 1:私はまだ適切なテーブル構造を持っていないので、例を挙げてみましょう: 公共交通機関の路線 (約 200) を保持するテーブルを用意します。これは、実際には一意の番号で識別されます。これはあらゆる種類のテーブルで参照され、あらゆる種類の操作が行われます。これらの参照テーブルには、最大量のデータが保持されます。

線には固有の番号があるため、3 つのデザイン例を考えました。

  1. PK はデータ型の行番号です: smallint

  2. PK はデータ型の行番号です: int

  3. PK は別のもの (ID など) であり、行番号は別のフィールドに格納されます。

  4. 議論のために、最適化の対象ではない「入力データベース」でこれを使用したため、PK は GUID (16 バイト) です。必要に応じて、これが他のものと比べてどれほど悪いかを比較することができます。

したがって、PK は少なくとも 15 のテーブルで参照されることに注意してください。そのうちのいくつかは 50.000 を超える行 (上で述べたように残りの平均は 5.000) を持ち、これらは常にクエリと操作の対象となります。私が得ることができるすべての速度に興味があります。

必要に応じて、これをさらに詳しく説明できます。ありがとう

編集2:そして、これに関連する別の質問が頭に浮かびました。それはこの議論に当てはまると思います:

LINQ to SQL を使用するのではなく、.NET アプリケーション内からネイティブ SQL クエリを使用すると、この特定のシナリオでパフォーマンスが向上しますか? LINQ が強力に最適化されており、パフォーマンスに関して非常に優れたクエリを生成することは知っていますが、それでも、質問する価値は確かにあります。再度、感謝します。

4

3 に答える 3

4

データ型が小さいほど処理量が多いという記事をいくつか挙げていただけますか? SSD を使用しても、今日のほとんどのワークロードは I/O バウンド (またはメモリ バウンド) であり、CPU バウンドではないことに注意してください。

特に、PK が多くのテーブルで参照される場合は、可能な限り最小のデータ型を使用すると効果的です。この場合、SMALLINTそれが私が使用するものです(ただし、約200の値があると言うので、理論的TINYINTには半分のサイズで0〜255をサポートするものを使用できます)。注意が必要なのは、常に ~200 の値が存在することを 100% 確信していない場合です。256 が必要になったら、影響を受けるすべてのテーブルのデータ型を変更する必要があり、これは面倒です。そのため、将来の成長に対応することと、現在のパフォーマンスを最大限に引き出すこととの間でトレードオフが生じることがあります。255 または 32,000 の値を決して超えないことが確実にわからない場合は、おそらくINT. 20 億の値を超えることはないということも知らない限り、その場合はBIGINT.

INT/ SMALLINT/の違いTINYINTは、パフォーマンスよりもディスク容量で顕著になります。(また、Enterprise を使用している場合、ディスク容量とパフォーマンスの両方の違いは、データ圧縮を使用してかなり相殺できます。特に、値がすべて/INT内に収まっている間は、後者の場合、値が一方、これらの と の違いは、パフォーマンスとディスク容量の両方ではるかに顕著になります。マークは、キンバリーからいくつかの素晴らしいリンクを提供しました。私がこの記事を書いたのは 2003 年で、少し古くなっていますが、今日でも重要な点のほとんどが含まれています。SMALLINTTINYINTGUID

時々考慮する必要があるもう 1 つのトレードオフ (特定のケースではないようですが) は、複数のシステム間で値を一意にする必要があるかどうかです。これは、ビジネス要件を満たすためにパフォーマンスをいくらか犠牲にする必要がある場合があります。多くの場合、人々は簡単な方法を取り、自分自身を辞任しGUIDます. SEQUENCEしかし、ID 範囲、中央のカスタム シーケンス ジェネレーター、SQL Server 2012 の新しいオブジェクトなど、他のソリューションもあります。SQL Server 2012の最初のパブリック ベータ版がリリースされた 2010 年について書きました。SEQUENCE

于 2012-04-22T13:52:07.770 に答える
0

テーブル構造とそれらに対して実行されるサンプル クエリについて、さらに詳細を提供する必要があると思います。あなたが提供した情報に基づいて、より小さなデータ型を選択することの影響はほんの数パーセントであると信じています.あなたが持つインデックスにもっと注意を払うことをお勧めします. SQL Server は、クエリの実行計画とチューニング アドバイザー ツールを提供することで、作成するインデックスを適切に提案します。

于 2012-04-22T10:15:42.023 に答える
-2

私が持っている 1 つの提案は、フィールドの組み合わせを使用する代わりに、decimal データ型を組み込むことです。たとえば、日付 (YYYYMMDD)、ストア (SSSS)、アイテム (IIII) を含むテーブルを作成する代わりに、YYYYMMDD.SSSSIIII をお勧めします。特に、この同じキーの組み合わせで複数のテーブルをクエリする場合、処理時間が劇的に改善されます。

于 2012-06-07T19:19:24.733 に答える