500 000エントリを含むテーブルを使用してHSQLDB
サーバーでいくつかのテストを実行しています。テーブルにはインデックスがありません。 5000の異なるビジネスキーがあります。それらのリストが必要です。当然、DISTINCT
クエリから始めました。
SELECT DISTINCT business_key FROM memory WHERE
concept <> 'case' or
attrib <> 'status' or
value <> 'closed'
約90秒かかります!!!
次に、GROUP BY
を使用してみました:
SELECT business_key FROM memory WHERE
concept <> 'case' or
attrib <> 'status' or
value <> 'closed'
GROUP BY business_key
そして、それは1秒かかります!!!
EXLAIN PLAN FOR
を実行した違いを理解しようとしましたが、両方のクエリに同じ情報を提供するようです。
EXLAIN PLAN FOR DISTINCT ...
isAggregated=[false]
columns=[
COLUMN: PUBLIC.MEMORY.BUSINESS_KEY
]
[range variable 1
join type=INNER
table=MEMORY
alias=M
access=FULL SCAN
condition = [ index=SYS_IDX_SYS_PK_10057_10058
other condition=[
OR arg_left=[
OR arg_left=[
NOT_EQUAL arg_left=[
COLUMN: PUBLIC.MEMORY.CONCEPT] arg_right=[
VALUE = case, TYPE = CHARACTER]] arg_right=[
NOT_EQUAL arg_left=[
COLUMN: PUBLIC.MEMORY.ATTRIB] arg_right=[
VALUE = status, TYPE = CHARACTER]]] arg_right=[
NOT_EQUAL arg_left=[
COLUMN: PUBLIC.MEMORY.VALUE] arg_right=[
VALUE = closed, TYPE = CHARACTER]]]
]
]]
PARAMETERS=[]
SUBQUERIES[]
Object References
PUBLIC.MEMORY
PUBLIC.MEMORY.CONCEPT
PUBLIC.MEMORY.ATTRIB
PUBLIC.MEMORY.VALUE
PUBLIC.MEMORY.BUSINESS_KEY
Read Locks
PUBLIC.MEMORY
WriteLocks
EXLAIN PLAN FOR SELECT ... GROUP BY ...
isDistinctSelect=[false]
isGrouped=[true]
isAggregated=[false]
columns=[
COLUMN: PUBLIC.MEMORY.BUSINESS_KEY
]
[range variable 1
join type=INNER
table=MEMORY
alias=M
access=FULL SCAN
condition = [ index=SYS_IDX_SYS_PK_10057_10058
other condition=[
OR arg_left=[
OR arg_left=[
NOT_EQUAL arg_left=[
COLUMN: PUBLIC.MEMORY.CONCEPT] arg_right=[
VALUE = case, TYPE = CHARACTER]] arg_right=[
NOT_EQUAL arg_left=[
COLUMN: PUBLIC.MEMORY.ATTRIB] arg_right=[
VALUE = status, TYPE = CHARACTER]]] arg_right=[
NOT_EQUAL arg_left=[
COLUMN: PUBLIC.MEMORY.VALUE] arg_right=[
VALUE = closed, TYPE = CHARACTER]]]
]
]]
groupColumns=[
COLUMN: PUBLIC.MEMORY.BUSINESS_KEY]
PARAMETERS=[]
SUBQUERIES[]
Object References
PUBLIC.MEMORY
PUBLIC.MEMORY.CONCEPT
PUBLIC.MEMORY.ATTRIB
PUBLIC.MEMORY.VALUE
PUBLIC.MEMORY.BUSINESS_KEY
Read Locks
PUBLIC.MEMORY
WriteLocks
[〜#〜] edit [〜#〜]:追加のテストを行いました。 HSQLDB
に500 000のレコードがあり、すべての個別のビジネスキーがあるため、DISTINCT
のパフォーマンスは3秒向上しました。これに対し、GROUP BY
は約9秒かかりました。
MySQL
では、両方のクエリで同じことが行われます。
MySQL:500 000行-5000個の個別のビジネスキー:両方のクエリ:0.5秒MySQL:500 000行-すべての個別のビジネスキー:SELECT DISTINCT ...
-11秒SELECT ... GROUP BY business_key
-13秒
したがって、問題はHSQLDB
にのみ関連しています。
なぜこのような劇的な違いがあるのかを誰かが説明できるなら、私はとても感謝しています。
2つのクエリは同じ質問を表しています。どうやらクエリオプティマイザーは2つの異なる実行計画を選択します。私の推測では、distinct
アプローチは次のように実行されます。
business_key
値を一時テーブルにコピーしますgroup by
は次のように実行できます。
business key
の各値をハッシュテーブルに保存して、テーブル全体をスキャンします最初の方法は、メモリ使用量に対して最適化されます。一時テーブルの一部をスワップアウトする必要がある場合でも、適切に機能します。 2番目の方法は速度を最適化しますが、多くの異なるキーがある場合は潜在的に大量のメモリを必要とします。
十分なメモリまたはいくつかの異なるキーがあるため、2番目の方法は最初の方法よりも優れています。 2つの実行プラン間で10倍、さらには100倍のパフォーマンスの違いが見られることは珍しくありません。