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

안녕하세요. 슝스스님조회 및 정렬 대상이 5~8행 정도로 적다면 메모리 상에서 마이크로초 단위로 즉시 정렬되므로 `Using filesort`를 신경 쓰지 않으셔도 됩니다.이를 지우려고 불필요한 복합 인덱스를 추가하면 오히려 CUD(생성,수정,삭제) 쓰기 성능이 저하되는 부작용이 커집니다.실무에서는 정렬 대상이 수천~수십만 건 이상으로 폭증해 디스크 정렬이 발생하거나, 실제 쿼리 응답 속도가 느려질 때를 기준으로 튜닝하시면 됩니다.감사합니다.

오타 제보 드립니다.

수강생님 감사합니다^^!다음 버전에 패치할게요!

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

안녕하세요. 안태승님말씀하신데로 UUID를 유니크 키로 쓰면 PK 직접 조회보다 탐색 단계가 하나 늘어나고(랜덤 I/O), 별도의 인덱스 저장 및 유지 비용이 발생하는 것이 맞습니다. 하지만 무작위 값인 UUID를 직접 PK(클러스터형 인덱스)로 쓰면 실제 데이터 자체가 뒤섞여 INSERT 시 극심한 성능 저하와 디스크 단편화가 발생하고, 이를 참조하는 모든 외래키(FK)와 인덱스의 크기가 비대해지는 훨씬 치명적인 문제가 생깁니다.따라서 외부에서 들어오는 첫 단건 조회(진입점)에서만 UUID 인덱스를 타는 약간의 비용을 감수하고, 실제 데이터 적재와 내부의 수많은 테이블 조인(JOIN)은 가볍고 빠른 숫자형 PK(Auto Increment)로 처리하는 것이 전체 시스템 성능상 압도적으로 유리합니다.만약 데이터가 아주 많아져서 UUID 세컨더리 인덱스의 정렬 비용조차 부담스럽다면, 시간순 정렬이 보장되는 UUID v7(또는 ULID)과 BINARY(16) 타입을 적용해 해결할 수 있습니다.감사합니다.

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

안녕하세요. 안태승님네, 결론부터 말씀드리면 랜덤 UUID 대신 Auto Increment(또는 순차적 키)로 변경하면 대용량 마이그레이션 및 대량 INSERT 성능이 수 배 이상 개선 될거에요.다만 데이터용량이 수백만건 정도라면 개선이 크지는 않으니, 실제 본인의 환경에 맞게 테스트해보고 선택하시는 것을 권장합니다.감사합니다.

실행 통계2 explain analyze 조인 쿼리

안녕하세요. 안태승님실행 시간이 너무 오래 걸려서 어려운 경우에는 EXPLAIN으로 개념만 이해하셔도 괜찮습니다.(EXPLAIN ANALYZE 실행하면 실제 쿼리를 호출하니 너무 오래 걸릴 수 있습니다.)중요한 것은 개념을 이해하는 것이니 개념이 이해되었다면 넘어가셔도 괜찮습니다 :)감사합니다.

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

안녕하세요.Jh P님현업에서도 LLM으로 쿼리를 작성하고, 실행 계획을 해석하고, 튜닝 아이디어를 얻는 일은 이미 흔해졌습니다. 다만 그렇다고 해서 "작성이 쉬워졌으니 처음부터 복잡하게 최적화하자"로 바뀌지는 않았습니다. 왜냐하면 실무에서 코드를 다룰 때 발생하는 진짜 비용은 '처음 작성할 때'가 아니라 '버그가 터졌을 때'와 '비즈니스 요구사항이 바뀔 때' 발생합니다.디버깅 한계: 서비스 장애가 났거나 데이터 정합성이 깨졌을 때, 100줄짜리 괴물 쿼리는 작성자 본인도, LLM도 문맥(도메인 규칙)을 100% 온전히 이해하고 즉각 수정하기 어렵습니다.리뷰와 협업: 복잡한 쿼리는 동료 개발자가 코드 리뷰 단계에서 잠재적 사이드 이펙트를 검증하기 어렵게 만듭니다. 결국 사람이 이해하고 통제할 수 있는 선에서 단순하게 쪼개는 설계가 훨씬 안전합니다.감사합니다.

기타 영역 중 언두로그

안녕하세요. 김상형님결론부터 말씀드리면, 강의와 서적의 설명이 서로 상충하는 것이 아니라 둘 다 맞는 이야기입니다. 언두 로그(Undo Log)가 다뤄지는 영역(메모리 vs 디스크)과 생애주기를 바라보는 관점의 차이에서 오는 오해입니다.언두 로그는 버퍼 풀(메모리)에서 빠르게 생성, 관리되지만, 데이터 일관성과 복구를 위해 디스크 파일(Undo Tablespace)에도 함께 저장되어 관리됩니다.감사합니다.

DataSourceUtils.releaseConnection 할때요 SQLException e 사용하는 이유등

안녕하세요. 백수님이 부분을 이해하려면 checked Exception과 uncheck Exception의 개념을 이해해야 합니다.이 부분은 자바 중급1편 그리고 스프링 DB1편에서 자세히 배울 수 있으니 해당 부분을 참고해주세요.감사합니다.

수업자료 오타

화를참자님 감사합니다! 다음 강의에 패치할게요^^!

복합인덱스 설계 질문

안녕하세요. 이성우님말씀하신 것처럼 product_status = 'ACTIVE' 비율이 85%라면 선택도가 낮기 때문에, (category_id, product_status, created_at)으로 확장했을 때 얻는 이득은 크지 않을 수 있습니다.실행 결과에서도 48건 → 40건으로 줄어드는 정도이니까요.그래서 이 정도라면 (category_id, created_at)만 사용하는 것도 충분히 합리적인 선택입니다. 인덱스도 저장 공간과 변경 비용이 있기 때문입니다.다만 판단할 때는 전체 테이블의 ACTIVE 비율보다 해당 category_id 내부에서 ACTIVE 비율이 얼마나 되는지를 보는 것이 더 중요합니다.결국 두 인덱스 모두 가능한 선택이고, 실제 데이터 분포와 쿼리 빈도, 성능 차이를 측정해서 결정하는 것이 가장 좋습니다.감사합니다 :)