13

int列でテーブルを検索する方が、文字列列（varcharなど）よりも高速であることが認められています。

ただし、Color列のあるShirtテーブルがある場合、そのテーブルの主キーがShirtテーブルの外部キーであるColorテーブルを作成する方がパフォーマンスが高くなりますか？結合により、シャツの[色]列の値が、緑のシャツを検索するときに「緑」などの文字列値ではなくintになるというパフォーマンス上の利点が無効になりますか？

4

5 に答える 5

20

私が正しく理解していれば、あなたはこれら2つのクエリのどちらが速いかを尋ねています。

SELECT * FROM shirt where color = 'Green'

vs

SELECT shirt.* FROM shirt s INNER JOIN colors c 
       ON s.colorid = c.colorid 
       WHERE c.color = 'Green'

データベースに少し依存しますが（正しく最適化されているかどうかによって大きく異なりますが、すべてではないにしてもほとんどの場合）、カラーテーブルでのルックアップは無視できるはずであり、残りの実行では整数を使用できます。ルックアップ値であり、より高速である必要があります。処理の大部分は、最終的にはと同等になりSELECT * from shirt WHERE colorid=Nます。ただし、テーブルがかなり大きくない限り、速度の違いに気付かないのではないかと思います。決定は、おそらくどの設計が最も理にかなっているのか（おそらく正規化された設計）に基づいて行う必要があります。

于 2012-09-14T20:02:52.113 に答える
11

パフォーマンスを超えて、個別のカラーテーブルを作成すると、デザインの正規化が向上します。したがって、将来、誰かが「ダークブルー」を「ネイビーブルー」と呼ぶことにした場合、カラーテーブルの1行を更新するのではなく、シャツテーブルの多くの行を更新します。

于 2012-09-14T20:01:08.020 に答える
7

実行されている他の操作と比較して、2つのアプローチの間に大きなパフォーマンスの違いがある可能性は低いです。ほんの一握りの色（最大数百色）しかない場合、ほとんどのデータベースの1ページにカラーテーブルが収まります。色のインデックスを使用すると、ルックアップが非常に高速になり、I / Oアクティビティが発生しなくなります（ページをロードするための最初の実行後）。

文字列の比較はデータベースによって異なりますが、関数とページからのデータの読み取りが含まれます。だから、それは無料ではありません。もちろん、データベースが異なれば、文字列関数のパフォーマンス特性も異なる可能性があります。

保存する場所は、アプリケーションの機能である必要があります。色がユーザーに表示されるアプリケーションがあるとします。ある日、スペイン語、スワヒリ語、または中国語で色の名前を表示したい場合があります。もしそうなら、別のテーブルを持つことはそのような国際化をはるかに簡単にします。もっと乱暴に言うと、「Grene」が入力されないようにしたい場合があります。その場合、そのようなテーブルがあると、選択リストが簡単になります。

一方、パフォーマンスが唯一の関心事である場合、それは違いはありません。その他の場合、ルックアップテーブルが非正規化テーブルよりも高速である可能性があります。これは、文字列が長く、大きなテーブルのすべてのレコードの長さが長くなる場合に発生します。テーブルが大きいほどページ数が多くなり、メモリへのロードに時間がかかります。

于 2012-09-14T20:05:15.677 に答える
4

DBMSには、値の数が限られている場合にインデックスを最適化する機会があります。sQLにこれを行うように指示する方法はわかりません。それはそれを理解するかもしれません。

レポートのパフォーマンスが深刻な問題である場合は、データウェアハウスを開始します。

Joeが指摘しているように、データベースは可能な限り正規化する必要があります。パフォーマンスの問題を引き起こす可能性のある別のレポート機能がある場合は、2番目の読み取り専用スキーマを定期的に変換する（またはリアルタイムでビルドするためのルールを設定する）必要があります。1つ目はOLTPで、2つ目はOLAP（「データウェアハウス」）です。これらは、データに真剣に取り組む場合に備えておくべき重要な概念です。

知ることが十分に重要である場合は、それをテストします。

誰もあなたに答えを与えない場合、それを行う最良の方法はあなた自身でテストすることです。

（1）2つのデータベースを作成する

（2）それぞれ2つのテーブルのテスト

（3）データベースでは、文字列'color'を結合し、それをFKに使用します。他はint（'colorID'）で結合します

それぞれに200万のダミー行を入力します。それぞれで複数のクエリを実行し、最初の実行と平均実行のタイミングを調整します。

開発マシンのインスタンスを使用して、ネットワークを全体像から外します。

また、各タイプのテストの前にインスタンスを開始および停止する必要があります。SQLがより高速に配信できるように、データは意図的にメモリに保持されますが、これにより、実際の操作からテスト結果が歪められる可能性があります。つまり、メモリ内にないか、キャッシュされていない可能性があります。

于 2012-09-14T20:07:50.867 に答える
1

それは本当にクエリオプティマイザに依存します。カラーテーブルは非常に小さいので、おそらくデータベース統計とクエリプランに基づいて、メモリに完全に読み込まれる可能性があります。そのため、結合のパフォーマンスコストを無効にするだけでなく、実際には高速になる可能性があります。これは明らかに使用しているdbmsによって異なりますが、いくつかのdbmsは、テーブルを特別な方法で処理するためのヒントを得ることができます。

Colorテーブルのもう1つの+1は、色の名前を変更する必要がある場合、出現するたびに文字列値を変更するのではなく、1回の更新で済むことです。

于 2012-09-14T20:03:02.387 に答える