안녕하세요. 김상형님 결론부터 말씀드리면, 강의와 서적의 설명이 서로 상충하는 것이 아니라 둘 다 맞는 이야기입니다. 언두 로그(Undo Log)가 다뤄지는 영역(메모리 vs 디스크)과 생애주기 를 바라보는 관점의 차이에서 오는 오해입니다. 언두 로그는 버퍼 풀(메모리)에서 빠르게 생성, 관리되지만, 데이터 일관성과 복구를 위해 디스크 파일(Undo Tablespace)에도 함께 저장되어 관리됩니다. 감사합니다.
안녕하세요. 이성우님 말씀하신 것처럼 product_status = 'ACTIVE' 비율이 85%라면 선택도가 낮기 때문에, (category_id, product_status, created_at)으로 확장했을 때 얻는 이득은 크지 않을 수 있습니다. 실행 결과에서도 48건 → 40건으로 줄어드는 정도이니까요. 그래서 이 정도라면 (category_id, created_at)만 사용하는 것도 충분히 합리적인 선택입니다. 인덱스도 저장 공간과 변경 비용이 있기 때문입니다. 다만 판단할 때는 전체 테이블의 ACTIVE 비율보다 해당 category_id 내부에서 ACTIVE 비율이 얼마나 되는지를 보는 것이 더 중요합니다. 결국 두 인덱스 모두 가능한 선택이고, 실제 데이터 분포와 쿼리 빈도, 성능 차이를 측정해서 결정하는 것이 가장 좋습니다. 감사합니다 :)
안녕하세요. 전성민님 리뉴얼이 되면 학습에서 조금 더 편한 부분들이 있겠지만, JPA의 경우 이미 완성에 가까운 기술이기 때문에 리뉴얼을 기다리기 보다는 먼저 듣는 것을 권장합니다 :) 리뉴얼의 경우 시간이 얼마나 걸릴지는 저도 작업을 진행해봐야 알 수 있을 것 같은데, 단기간에 되기는 어려울 것 같아요. 감사합니다.
안녕하세요. ggg7515님 어댑티브 해시 인덱스(AHI)도 탐색을 줄이는 건 맞지만, 절약하는 비용의 종류가 커버링 인덱스와 다릅니다. 커버링 인덱스는 세컨더리 인덱스 → 클러스터링 인덱스로 가는 추가 탐색 자체를 없앱니다. 접근할 페이지 수가 줄어들기 때문에, 해당 페이지가 버퍼 풀에 없다면 디스크 I/O까지 실제로 줄어듭니다. 반면 AHI는 버퍼 풀에 이미 올라와 있는 페이지에 대해서만 동작합니다. 자주 조회되는 키 값 → 버퍼 풀 내 레코드 위치를 해시로 매핑해두고, 루트 → 브랜치 → 리프로 내려가는 B+Tree 탐색을 건너뛰게 해줍니다. 즉 절약되는 건 메모리 안에서의 트리 탐색 비용(CPU)이지 디스크 I/O가 아닙니다. 페이지가 버퍼 풀에 없으면 어차피 디스크에서 읽어야 하고, 이 경우 AHI는 도움이 되지 않습니다. 정리하면 커버링 인덱스는 I/O 최적화, AHI는 CPU 최적화입니다. 그리고 한 가지 중요한 점은, MySQL 8.4부터 AHI가 기본 비활성화로 바뀌었다는 것입니다. 현대 워크로드에서는 이점보다 경합, 유지 비용이 더 큰 경우가 많다는 판단이 반영된 변경입니다. 감사합니다.