그룹 별 사용과 구별 사용시 큰 성능 차이
HSQLDB
500,000 개의 항목이 포함 된 테이블이 있는 서버 에서 몇 가지 테스트를 수행하고 있습니다. 테이블에 인덱스가 없습니다. 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
편집 : 추가 테스트를 수행했습니다. HSQLDB
모든 고유 한 비즈니스 키가 포함 된 500,000 개의 레코드를 사용 하여 DISTINCT
이제 성능이 향상되었습니다 ( GROUP BY
약 9 초 소요).
에서 MySQL
두 쿼리 같은 미리 형성 :
MySQL: 500 000 rows - 5 000 distinct business keys: Both queries: 0.5 second MySQL: 500 000 rows - all distinct business keys: SELECT DISTINCT ...
- 11 seconds SELECT ... GROUP BY business_key
- 13 seconds
So the problem is only related to HSQLDB
.
I will be very grateful if someone can explain why there is such a drastic difference.
The two queries express the same question. Apparently the query optimizer chooses two different execution plans. My guess would be that the distinct
approach is executed like:
- Copy all
business_key
values to a temporary table - Sort the temporary table
- Scan the temporary table, returning each item that is different from the one before it
The group by
could be executed like:
- Scan the full table, storing each value of
business key
in a hashtable - Return the keys of the hashtable
The first method optimizes for memory usage: it would still perform reasonably well when part of the temporary table has to be swapped out. The second method optimizes for speed, but potentially requires a large amount of memory if there are a lot of different keys.
Since you either have enough memory or few different keys, the second method outperforms the first. It's not unusual to see performance differences of 10x or even 100x between two execution plans.
'Programing' 카테고리의 다른 글
레거시 C / C ++ 프로젝트에서 데드 코드 감지 (0) | 2020.11.09 |
---|---|
기록이있는 저장소 간 SVN 사본 (0) | 2020.11.09 |
Manacher의 알고리즘 (선형 시간에서 가장 긴 회문 부분 문자열을 찾는 알고리즘) (0) | 2020.11.09 |
R의 python dict에 해당 (0) | 2020.11.09 |
PostgreSQL과 MySQL은 얼마나 다른가요? (0) | 2020.11.09 |