안녕하세요. 인덱스 관련 질문 있습니다.
에피소드 15에서 복합 인덱스의 경우 순서가 중요하다고 하셨는데요.
그럼 인덱스 생성 시 (account_type, joined_at) 와 같은 순서일때 조건에 joined_at account_type 순서로 주어지면 인덱스를 활용하지 못하는게 맞을까요??
Câu trả lời 2
2
안녕하세요. 답변이 늦었습니다.
인덱스가 (account_type, joined_at)과 같이 존재할 때, 쿼리 WHERE 절에는 (joined_at, account_type) 순서로 조건이 주어졌다고해서 인덱스를 활용하지 못하는 것은 아닙니다.
인덱스를 구성하는 컬럼들이 모두 조건으로 주어져있기 때문에 인덱스는 당연히 사용이 가능합니다.
쿼리 WHERE 절에 나열된 순서가 인덱스 내 컬럼 순서와 다르더라도 MySQL 옵티마이저는 인덱스를 사용할 수 있는 조건들을 추려내서 인덱스를 활용하는 최적화를 수행하기 때문에, 순서는 크게 중요하지 않고 인덱스를 구성하고 있는 컬럼들이 조건으로 주어져 있는지가 더 중요하다고 봐주시면 좋을 것 같아요.
그리고 추가적으로 쿼리에서 컬럼들에 주어진 조건 형태에 따라 인덱스 내 컬럼 순서가 쿼리 처리 효율에 영향을 줄 수 있는데요.
예를 들어, 아래와 같이 쿼리에서 인덱스를 구성하는 컬럼들 모두 동등 조건으로 조건값이 주어진 경우에는 인덱스 내의 컬럼 순서는 어떤 순서든 크게 상관이 없습니다.
SELECT *
FROM tab1
WHERE account_type = ?
AND joined_at = ?그러나 아래와 같이 joined_at이 동등 조건이 아닌 범위 조건으로 사용된 경우에는, 인덱스 내 컬럼 순서가 (account_type, joined_at) 인 것이 좋습니다.
SELECT *
FROM tab1
WHERE account_type = ?
AND joined_at >= ? AND joined_at < ?(account_type, joined_at) 으로 인덱스가 구성돼있는 경우, 쿼리 처리 시 인덱스에서 실제 조건에 만족하는 인덱스 데이터들만 스캔하지만, (joined_at, account_type) 순서로 인덱스가 구성돼있는 경우 인덱스 선두에 위치한 joined_at 조건 범위에 속한 인덱스 데이터를 모두 스캔하게 되기 때문입니다.
관련해서 모든 내용을 댓글로 다 설명드리기는 어려워서.. 혹시 Real MySQL 8.0 책 1권을 가지고 계시다면, "8.3.7.1 비교 조건의 종류와 효율성" 부분을 읽어보시는 것을 추천드립니다.
추가로 궁금한 부분 있으시면 다시 말씀해주세요.
감사합니다.
0
안녕하세요, 인프런 AI 인턴입니다.
ned.choi님, 복합 인덱스에서 순서는 매우 중요합니다. 기본적으로 (account_type, joined_at) 순서로 인덱스를 생성했다면, WHERE 절의 조건도 이와 동일한 순서로 제시되어야 인덱스를 효율적으로 활용할 수 있습니다.
즉, 조건에 joined_at, account_type 순서로 주어진다면, 설계된 복합 인덱스의 효율을 온전히 활용하지 못할 수 있습니다. 인덱스는 왼쪽부터 오른쪽으로 순서대로 사용되기 때문에, 첫 번째 컬럼이 조건에 포함되지 않으면 이후 컬럼의 인덱스도 활용하지 못하는 경우가 발생합니다.
단, 일부 데이터베이스 시스템에서는 쿼리 최적화를 통해 컬럼의 순서와 관계없이 인덱스를 활용할 수 있게 하는 경우도 있지만, 이는 보장된 동작이 아니므로 인덱스 설계 시 주의해야 합니다.
라이브 운영중인 환경의 테이블에 인덱스 추가시 고려사항
0
21
2
JPA Repository 질문이 있습니다!
1
29
2
페이지네이션 처리를 쿼리에서 하는 방식 질문
1
31
1
DDD 는 마이바티스와 잘 맞지 않는건가요?
0
38
1
스프링부트 버전 문의드립니다.
0
29
1
Json 요청 처리
1
26
2
비동기 스레드풀 분리 이유와 Virtual Thread 전환 시 고려사항
0
26
1
gRPC 실무에서 질문
0
30
2
수강기간 연장
0
20
1
Build 관련 문제 (테스트 관련 문제)
0
30
1
unique index가 걸린 상황에서 s-lock, x-lock 질문
0
507
2
질문드립니다.
0
250
1
Real MySQL 시즌1 part 2 에피소드 16의 인덱스가 null인 컬럼을 포함한다는 것에 대한 질문
0
170
1
시퀸셜하게 증가하지 않는 PK의 insert성능도 문제가 있을까요?
0
222
2
파티셔닝의 자원 사용 효율 증가 관련 질문
1
644
2
INSERT에서 shared lock을 거는 이유 질문
1
434
3
테이블이 1:N 구조에서 N쪽 테이블에 유니크 제약조건에 의한 오류발생 회피 방법이 뭘까요?
0
262
1
복합 인덱스의 컬럼중 선행 컬럼을 조건에서 누락해도 인덱스가 사용될 수도 있나요?
0
239
1
SKIP LOCKED 부분에서 INNER JOIN이 아니고 LEFT JOIN이 걸릴수 있다면
0
184
1
단일 인덱스 크기, 전체 인덱스 크기 구하는 계산식
0
235
2
primary key에 시간, uuid로 복합키로 설정하는 경우
0
325
2
에피소드 21에 궁금한 점이 있어 질문드립니다.
0
233
2
에피소드 17번에서 skip locked 질문이 있습니다.
0
265
1
Real MySQL 시즌 1 - Part 1 or Part2 영상에 나오는 자료 공유 가능하나요?
1
364
1

