일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
Tags
- 스트림
- IntellJ
- mysql
- Stack
- K8s
- 자바
- 쿠버네티스
- 이스티오
- gradle
- redis
- OS
- Kotlin
- list
- 토비의 스프링
- Java
- 토비의 스프링 정리
- jvm
- GC
- thread
- Collection
- 보조스트림
- spring
- 자바 ORM 표준 JPA 프로그래밍
- 스프링
- SpringBoot
- 백준
- Stream
- MSA
- Real MySQL
- JPA
Archives
- Today
- Total
인생을 코딩하다.
[mySql, postgreSql] where절과 join절 작성 순서는 query의 성능과 연관이 있을까요? 본문
728x90
반응형
where절 작성 순서는 query 성능과 연관이 있을까요?
SELECT *
FROM hyungil.user AS u
....
WHERE u.id = ?
AND u.name = ?
AND u.date = ?
- 상관없습니다. Query Optimizer의 최적화 알고리즘에 의해 알아서 최적화됩니다. 비즈니스 로직의 순서에 맞춰서 작성하면 됩니다.
FROM절 작성 순서는 query 성능과 연관이 있을까요?
INNER JOIN
SELECT *
FROM hyungil.A
INNER JOIN hyungil.B
ON A.col = B.col
INNER JOIN hyungil.C
ON C.col = B.col
- INNER JOIN은 Query Optimizer의 최적화 알고리즘(순서가 달라도 결과가 같아야 한다.)에 의해 알아서 최적화됩니다. 비즈니스 로직의 순서에 맞춰서 작성하면 됩니다.
OUTER JOIN
SELECT *
FROM hyungil.A
OUTER JOIN hyungil.B
ON A.col = B.col
OUTER JOIN hyungil.C
ON C.col = B.col
- OUTER JOIN은 순서에 따라 결과가 바뀝니다. 따라서 Query Optimizer의 최적화되지 않고, 작성 순서와 동일하게 실행됩니다.
스키마 이름은 query 성능과 연관이 있을까요?
SELECT * FROM hyungil.A?
or
SELECT * FROM A?
결론부터 말씀드리자면 스키마 이름도 작성해주는게 좋습니다. sequence 입장에서는 개체 이름을 가지고 개체 유일성을 식별하고 확보하는데 있어서 스키마 이름 부분이 필요합니다. Query Optimizer에서는 스키마 이름을 찾기 위한 개체 이름 해석과정이 진행되게 되는데, 이때 스키마 이름이 생략되어 있다면, 스키마 이름을 찾기위한 불필요한 오버헤드가 발생합니다. 이 오버헤드는 아주 적지만 모이고 모이면 꽤나 큰 오버헤드가 될 것 입니다.
728x90
반응형
'DataBase' 카테고리의 다른 글
postgreSql using brin index란? (0) | 2023.12.20 |
---|---|
[Redis] Redis Pipeline (0) | 2023.10.03 |
[MySQL] MySQL 실행 계획 분석을 통해 페이징 쿼리 성능 개선 (0) | 2021.08.28 |
[MySQL] 외래키(Foreign Key)와 데드락(DeadLock) (0) | 2021.08.12 |
[MySQL] 트레픽 분산을 위한 Master/Slave DataSource 동적 라우팅 설정 (0) | 2021.08.10 |
Comments