私は次のクエリがある場合:インデックス
CREATE INDEX example_table_key1 ON example.example_table(key1);
CREATE INDEX example_table_key2 ON example.example_table(key2);
または単一のインデックス:このクエリの
SELECT *
FROM example.example_table et
WHERE et.key1 = 10 OR et.key2 = 10
を、パフォーマンスが賢明二つの別々のインデックスを作成することをお勧めし
CREATE INDEX example_table_key1_key2 ON example.example_table(key1, key2)
それは問題ではありませんか?私は2つの指標にもっと傾いています。
AND
については、後者を使用する方が良いことがわかります。
より「複雑な」クエリの場合はどう:
SELECT *
FROM example.example_table et
WHERE et.key1 = 10 OR et.key2 = 10
AND et.key3 = 10
私はOR
を有する次のことを書くと同じであることをどこかで聞いた:
SELECT *
FROM example.example_table et
WHERE et.key1 = 10
AND et.key3 = 10
UNION ALL
SELECT *
FROM example.example_table et
WHERE et.key2 = 10
AND et.key3 = 10
これは意味があります。その場合、次の2つのインデックスが最適であると思います。
CREATE INDEX example_table_key1_key3 ON example.example_table(key1, key3);
CREATE INDEX example_table_key2_key3 ON example.example_table(key2, key3);
しかし、key3のインデックスを2回使用すると2つのヘルプが役立つとは思いません...その場合、3つのキーすべてに対して1つのインデックスを作成しますか?
CREATE INDEX example_table_key1_key2_key3 ON example.example_table(key1, key2, key3)
私は3つのキーを持つテーブルは、一般的に悪い習慣(それはOR
を必要とする場合は特に)ですが、私の実際の生活例えば、私は、データベースを設計していなかった知っています。また、テーブルはインデックスに登録されていません...コードや他のテーブルもこれらのテーブルに依存しているため、デザインを変更すると生産に影響が出る可能性があります。
また、使用例に合ったビットマップインデックスを使用してください。または、テーブルを分割するか、ハッシュクラスタを使うか、...テーブルのサイズとカラムのデータの分布に強く依存する非常に多くのオプションがあると思います。しかし、はい、一般的に、あなたの答えは一般的に言えば最高です。 – nop77svk
SQLを動的に生成していて、ORが必要な場合はどうなりますか?私はこのパフォーマンスヒットで立ち往生していますか? – Mocking
@Mocking残念ながら、あなたはそれに立ち往生しています。 – Bohemian