inflearn logo
강의

Khóa học

Chia sẻ kiến thức

Chuẩn bị phỏng vấn CS – Phần Cơ sở dữ liệu, chia sẻ trực tiếp từ người phỏng vấn của Channel Talk

(Câu hỏi phụ) Nếu đồng nghiệp đề xuất tạo chỉ mục cho kiểu Bool, bạn sẽ đưa ra ý kiến gì? ⭐️⭐️

Boolean 컬럼 인덱스와 Cardinality에 따른 실행 계획에 대하여

Đã giải quyết

102

ffdfig1967

2 câu hỏi đã được viết

1

강의를 듣다가 궁금한 부분이 있어 질문드립니다!

Secondary Index를 사용하면 Primary(Clustering) Index Lookup 과정에서 랜덤 I/O가 발생할 수 있다고 이해하고 있습니다

다만 이는 Cardinality가 낮은 Boolean 컬럼에만 국한된 문제라기보다는, Secondary Index의 정렬 순서와 PK 순서가 일치하지 않는 경우 일반적으로 발생할 수 있는 문제라고 생각합니다

또한 MySQL에서는 MRR을 통해 조회 대상 PK를 정렬한 뒤 접근함으로써 랜덤 I/O를 줄일 수도 있는 것으로 알고 있습니다

강의에서는 Boolean 컬럼의 경우 특정 값이 전체 데이터의 상당 부분을 차지할 가능성이 높기 때문에, MRR을 통한 정렬 및 테이블 Lookup보다 Full Table Scan이 더 효율적일 수 있다는 취지로 설명해주신 것으로 이해했습니다

그렇다면 인덱스의 효율은 Cardinality 자체만으로 결정된다기보다, 실제 값의 분포와 선택도, 예상 조회 행 수, Covering Index 여부, MRR 적용 여부 등의 요인을 함께 고려해 판단한다고 이해해도 될까요?

DBMS/RDBMS innodb mysql

Câu trả lời 1

1

jayon0927

안녕하세요, 소준영님!

좋은 질문입니다. 말씀하신 이해가 맞습니다.


강의에서는 카디널리티를 인덱스 효율을 판단하는 대표적인 기준으로 설명했지만, 실제 실행 계획은 값의 분포와 선택도, 예상 조회 행 수, Covering Index 여부, MRR 적용 여부 등을 함께 고려해 결정됩니다.


Boolean 컬럼도 데이터가 한쪽으로 치우쳐 있다면, 소수 값을 조회할 때는 인덱스가 효율적일 수 있습니다. 예를 들어 true가 전체의 0.1%라면 WHERE flag = true에는 인덱스가 유리할 수 있지만, 나머지 99.9%를 조회하는 WHERE flag = false에는 Full Table Scan이 더 유리할 수 있습니다.


또한 같은 선택도라도 조회 대상 행이 PK 순서상 가까운 범위에 모여 있는지, 테이블 전체에 흩어져 있는지에 따라 실제 페이지 접근 비용이 달라질 수 있습니다. 이런 의미에서 Secondary Index 컬럼과 Clustered Index 순서 사이의 correlation도 성능에 영향을 줄 수 있습니다.


정리하면 카디널리티는 절대적인 기준이라기보다 중요한 판단 요소 중 하나이며, 최종적으로는 실제 데이터 분포와 EXPLAIN ANALYZE 결과를 함께 확인하는 것이 가장 정확합니다.


다만, 강의에서는 이를 모두 다루기에 과하다고 생각하여 가장 일반적인 판단 기준인 카디널리티를 대표적으로 설명하였습니다!

1

ffdfig1967

오.. Correlation에 대해서까지는 생각을 안해봤는데 그렇겠네요 . . !
예를 들어 Auto Increment를 적용하고 있는 PK가 존재하는 테이블에 UUID를 Secondary Index로 두는 경우, v4가 아닌 v7으로 둔다면 성능 향상을 기대할 수 있어보이네요

이건 Disk I/O 과정에서 페이지 단위로 데이터를 가져오기 때문에 Disk I/O를 줄일 수 있고 MRR 과정 자체에서도 정렬 비용을 일부 아낄 수 있다고 생각이 드는데 올바른 추론일까요?

1

jayon0927

네, 전반적인 추론은 맞습니다!


UUID v7은 생성 시간 순서가 반영되기 때문에 Auto Increment PK와 비슷한 순서로 쌓일 가능성이 높습니다. 따라서 UUID 범위 조회 시 함께 조회되는 PK들도 서로 가까울 가능성이 커지고, Clustered Index의 인접한 페이지를 연속해서 읽을 수 있어 Disk I/O 감소를 기대할 수 있습니다.


다만 이런 효과는 단건 조회보다 여러 건을 범위로 조회할 때 더 의미가 큽니다. 또한 MRR은 조회 대상 PK를 별도로 모아 정렬하므로, UUIDv7이 MRR의 정렬 비용까지 직접 줄인다고 단정하기보다는 정렬 이후 실제 데이터 페이지 접근이 더 효율적일 수 있다고 보는 편이 정확합니다.


결국 복잡한 쿼리이거나 많은 데이터를 질의해야하는 경우 실행 계획을 통해 실측을 하시는 것을 권장합니다 :)

1

ffdfig1967

늦은 시간까지 친절한 답변 주셔 정말 감사합니다 !
늘 강의 보고 잘 배우고 있습니다 :D

강의 소스코드는 어디서 다운받을 수 있나요?

1

55

2

힌트 적용에 대해서

0

55

1

수료증 제공하나요?

0

49

1

조회 대상 행이 적을 때도 Using filesort 제거를 고려해야 하나요?

0

66

2

PK를 AUTO_INCREMENT UUID를 UNIQUE로 하는것에 대해

0

71

2

Jib 빌드가 83%에서 멈추는 문제 해결(windows 사용자)

1

61

1

pk를 auto increment로 하는것에 대해서

0

66

2

트랜잭션 내 Redis I/O 에 대한 궁금한점

1

54

1

경쟁상태

0

67

1

stmt

0

58

1

실행 통계2 explain analyze 조인 쿼리

0

69

1

[해결됨]마지막 강의 내용 수정 화면이 기능을 못하네요.

0

62

1

[해결됨]부분적으로 화면 이동이 안되는 부분이 있습니다.

0

95

6

68강 문제 풀이

0

50

1

현대 쿼리 복잡성에 관한 질문

0

123

3

key_length 가 사용되는곳

0

55

1

낙관적락 질문있습니다.

0

59

1

댓글순서부여방식

0

61

1

공통 코드 VS Enum 클래스

1

72

1

movablePageCount와 pageSize 상수

0

48

1

JPA와 네이티브 쿼리

0

63

1

aws 계정 생성 질문

1

95

1

강의 DB데이터 질문

0

80

1

극단적으로 from-to가 12일 이고, valid_to가 13일이면?

0

68

1