질문&답변
DataSourceUtils.releaseConnection 할때요 SQLException e 사용하는 이유등
안녕하세요. 백수님 이 부분을 이해하려면 checked Exception과 uncheck Exception의 개념을 이해해야 합니다. 이 부분은 자바 중급1편 그리고 스프링 DB1편에서 자세히 배울 수 있으니 해당 부분을 참고해주세요. 감사합니다.
- 좋아요수
- 0
- 댓글수
- 2
- 조회수
- 58
질문&답변
안녕하세요. 백수님 이 부분을 이해하려면 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 비율이 얼마나 되는지를 보는 것이 더 중요합니다. 결국 두 인덱스 모두 가능한 선택이고, 실제 데이터 분포와 쿼리 빈도, 성능 차이를 측정해서 결정하는 것이 가장 좋습니다. 감사합니다 :)
질문&답변
안녕하세요. dkatn님 성공 결과("success")를 성공("sucess")으로 알아보지 못하고 에러(isError() == true)로 잘못 판단하여, 데이터 전송 단계로 넘어가지 못하고 에러 로그를 출력하며 정상 흐름이 끊기게 된 것입니다 감사합니다.
질문&답변
안녕하세요. isbcom1004님 스프링 최신 버전으로 진행하시면 됩니다^^! 감사합니다.
질문&답변
안녕하세요. 전성민님 리뉴얼이 되면 학습에서 조금 더 편한 부분들이 있겠지만, JPA의 경우 이미 완성에 가까운 기술이기 때문에 리뉴얼을 기다리기 보다는 먼저 듣는 것을 권장합니다 :) 리뉴얼의 경우 시간이 얼마나 걸릴지는 저도 작업을 진행해봐야 알 수 있을 것 같은데, 단기간에 되기는 어려울 것 같아요. 감사합니다.
질문&답변
jhpride님 이렇게 남겨주셔서 감사합니다 :) SQL을 배워두시면 AI가 제대로 작업을 했는지도 더 쉽게 이해하실 수 있을거에요. 그리고 AI에게도 작업을 더 잘 시키실 수 있을거에요 :)
질문&답변
안녕하세요. ggg7515님 어댑티브 해시 인덱스(AHI)도 탐색을 줄이는 건 맞지만, 절약하는 비용의 종류가 커버링 인덱스와 다릅니다. 커버링 인덱스는 세컨더리 인덱스 → 클러스터링 인덱스로 가는 추가 탐색 자체를 없앱니다. 접근할 페이지 수가 줄어들기 때문에, 해당 페이지가 버퍼 풀에 없다면 디스크 I/O까지 실제로 줄어듭니다. 반면 AHI는 버퍼 풀에 이미 올라와 있는 페이지에 대해서만 동작합니다. 자주 조회되는 키 값 → 버퍼 풀 내 레코드 위치를 해시로 매핑해두고, 루트 → 브랜치 → 리프로 내려가는 B+Tree 탐색을 건너뛰게 해줍니다. 즉 절약되는 건 메모리 안에서의 트리 탐색 비용(CPU)이지 디스크 I/O가 아닙니다. 페이지가 버퍼 풀에 없으면 어차피 디스크에서 읽어야 하고, 이 경우 AHI는 도움이 되지 않습니다. 정리하면 커버링 인덱스는 I/O 최적화, AHI는 CPU 최적화입니다. 그리고 한 가지 중요한 점은, MySQL 8.4부터 AHI가 기본 비활성화로 바뀌었다는 것입니다. 현대 워크로드에서는 이점보다 경합, 유지 비용이 더 큰 경우가 많다는 판단이 반영된 변경입니다. 감사합니다.
질문&답변
Gomgomi님 다음 강의에서 필요한 내용을 얻으셨군요 ㅎㅎ 아마도 궁금해하실 것 같아서 복선을 깔아두었는데, 거기 걸리셨습니다 ㅎㅎㅎ 감사합니다.
질문&답변
안녕하세요. backendman님 결론부터 말하면 MySQL 8.0.24 기준으로 트레이드오프는 거의 없습니다. InnoDB의 ANALYZE TABLE 은 테이블 전체를 스캔하는 게 아니라 인덱스별로 일부 페이지만 샘플링합니다(기본 20페이지). 그래서 수억 건 테이블도 보통 수 초 안에 끝나고 부하도 미미합니다. 실무에서는 문제가 반복되는 테이블에 새벽 배치로 ANALYZE TABLE 을 정기 실행하는 게 흔한 패턴입니다. 자동 재계산이 "행의 10% 변경" 시점에만 동작해서 대용량 테이블은 통계가 낡기 쉽기 때문입니다. USE INDEX 는 즉효약이지만 플랜을 고정시켜서 데이터 분포가 바뀌어도 옛 플랜을 강제하는 유지보수 리스크가 있습니다. 통계 갱신으로 옵티마이저가 스스로 올바른 판단을 하게 만드는 게 근본 해결이고, 힌트는 그래도 안 되는 특수 케이스에만 남기는 걸 권장합니다. 감사합니다.