반응형

SQL 2

5편. 실행 계획을 믿으면 안 되는 이유

4편에서 인덱스의 내부 구조를 기준으로 왜 읽기는 빠르고 쓰기는 느릴 수밖에 없는지 살펴봤다.이제 실무에서 가장 자주 나오는 질문으로 넘어가 보자.“인덱스도 있는데, 왜 실행 계획이 풀스캔을 선택했지?”이 상황에서 흔히 이런 결론에 도달한다.“옵티마이저가 잘못 판단했다.”반은 맞고, 반은 틀리다. 실행 계획을 이해하려면, 먼저 옵티마이저가 무엇을 할 수 있고, 무엇을 할 수 없는지를 정확히 알아야 한다.MySQL 옵티마이저의 역할MySQL 옵티마이저는 SQL을 실행하기 전에 가능한 여러 실행 방법을 비교한다.그리고 그중에서 비용(cost)이 가장 낮다고 추정되는 계획을 선택한다.중요한 점은, 이 비용이 실제 비용이 아니라 추정 비용라는 것이다.옵티마이저는 무엇을 보고 판단할까옵티마이저는 다음 정보를 기반..

Database/MySQL 2026.02.01

[Spring JPA 공식 문서 기반] 2. JPA는 SQL을 없애지 않았다 – ORM의 책임 경계

1편에서는 ORM과 JPA가 무엇을 해결하려 했는지를 살펴봤습니다.이번 글에서는 그 문제 정의에서 자연스럽게 이어지는 가장 중요한 질문을 다뤄보겠습니다.JPA를 쓰면 정말 SQL을 안 써도 되는 걸까?이 질문에 대한 오해가 JPA 사용에서 발생하는 대부분의 문제의 출발점입니다.1. JPA = SQL 제거라는 오해JPA를 처음 접할 때 많이 듣는 설명은 대체로 이렇습니다.SQL을 직접 작성하지 않아도 된다객체만 다루면 된다이 설명은 절반만 맞고, 절반은 틀립니다.JPA를 사용한다고 해서 SQL이 사라지는 것은 아닙니다.SQL은 “보이지 않게” 될 뿐입니다.그리고 이 차이를 이해하지 못하면, JPA는 곧바로“이유 없이 느린 기술”로 보이기 시작합니다.2. 공식 문서가 말하는 ORM의 역할Spring JPA ..

반응형