web-dev-qa-db-ja.com

大きなテーブルと小さなテーブル間の内部結合の高速化

これはばかげた質問かもしれませんが、結合が内部でどのように機能するかについていくつかの光を当てるかもしれません。

大きなテーブルLと小さなテーブルSがあるとしましょう（100K行vs 100行）。

次の2つのオプション間で速度の点で違いはありますか？

OPTION 1:                 OPTION 2:
---------                 ---------
SELECT *                  SELECT *
FROM L INNER JOIN S       FROM S INNER JOIN L
ON L.id = S.id;           ON L.id = S.id;

唯一の違いは、テーブルが結合される順序です。

パフォーマンスはSQL言語によって異なる場合があることを理解しています。もしそうなら、MySQLはAccessとどのように比較されますか？

sqlquery-optimization
34
Zaid

いいえ、順序は関係ありません。

ほとんどすべてのRDBMS（MS Access、MySQL、SQL Server、Oracleなど）は、列統計に基づくコストベースのオプティマイザを使用します。ほとんどの場合、オプティマイザは正しい計画を選択します。あなたが与えた例では、順序は関係ありません（提供された統計は最新です）。

使用するクエリ戦略を決定するために、Jet Engineオプティマイザーは統計を使用します。以下の要因は、これらの統計が基づく要因の一部です。

  • テーブル内のレコード数
  • テーブル内のデータページの数
  • テーブルの場所
  • インデックスが存在するかどうか
  • インデックスの一意性

注：Jetデータベースエンジンの最適化スキームを表示したり、クエリを最適化する方法を指定したりすることはできません。ただし、Database Documenterを使用して、インデックスが存在するかどうか、およびインデックスの一意性を判断できます。

これらの統計に基づいて、オプティマイザーは特定のクエリを処理するための最適な内部クエリ戦略を選択します。

統計は、クエリがコンパイルされるたびに更新されます。クエリ（またはその基になるテーブル）への変更を保存するとき、およびデータベースが圧縮されるときに、クエリにはコンパイルのフラグが付けられます。クエリにコンパイルのフラグが付けられている場合、統計のコンパイルと更新は、次にクエリが実行されたときに行われます。通常、コンパイルには1秒から4秒かかります。

データベースに大量のレコードを追加する場合は、クエリを開いて保存し、クエリを再コンパイルする必要があります。たとえば、サンプルデータの小さなセットを使用してクエリを設計してテストする場合、追加のレコードがデータベースに追加された後にクエリを再コンパイルする必要があります。これを行うときは、アプリケーションの使用時に最適なクエリパフォーマンスが確実に達成されるようにする必要があります。

参照 。

興味があるかもしれません： ACC：Microsoft Access 2.0、Microsoft Access 95、およびMicrosoft Access 97でクエリを最適化する方法

Tony Toewsの Microsoft Access Performance FAQ は一読の価値があります。

21
Mitch Wheat

私はOracleがリストに載っていないことを知っていますが、最新のデータベースのほとんどはそのように動作すると思います。

次の実行プランを見ると、2つのステートメントに違いがないことがわかります。

これは、2つのテーブル（私の場合はインデックスなし）への完全アクセスであり、次にHASH JOIN。両方のテーブルのすべてが必要なので、両方のテーブルを読み取り、結合する必要があるため、シーケンスに影響はありません。

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |   100 |   700 |    42  (12)| 00:00:01 |
|*  1 |  HASH JOIN         |      |   100 |   700 |    42  (12)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| S    |   100 |   300 |     2   (0)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| L    |   100K|   390K|    38   (8)| 00:00:01 |
---------------------------------------------------------------------------
3
Peter Lang