현재 친절한 SQL 튜닝을 읽고 있습니다. 그러던 중 Between And 과 Where 부등호 사이의 성능 차이가 있다는 말을 들었고 직접 Test를 진행했습니다.
현재 친절한 SQL 튜닝을 읽고 있다. 책을 보고 있는 도중에 between, where, in 등의 의문이 들었고 많이 질문을 하면서 얘기하는 도중에 between and 과 >=, <= 의 성능차이가 있다는 것을 들었다. 책에도 나오지 않았기에 의아했고 50만개의 더미데이터를 이용해서 직접 테스트를 하려한다. 과거 1년 동안은 그렇구나 하고 끝냈다면 이제는 귀찮더라도... 해봐야지
더미데이터를 넣기전에 테스트를 할 Entity를 설정했다. 여기서 AccessLeve, GenerationType 같은 경우는 따로 포스팅을 할 계획이다.
딱히 없다. 어느 정도의 Data를 만들고 2018년부터 현재까지 데이터를 하루 단위로 넣어주었다.
첫 번째로 해볼 것은 Explain 이다. Explain을 우선적으로보고 차이점이 있는지 확인을 하자.
우선 전제로 두어야할 것은 인덱스와 Where절에 DATE TYPE을 고려하지 않고 모든 조건에 맞게끔 TEST를 하였다. 우선 부등호 부터 성능조사를 해보자.
혹여나 캐시를 확인하자. 캐시가 없다는 것을 확인했다.
곧바로 Between으로 성능을 테스트하자
결과적으로 확실히 Between 보다는 Where 을 이용하여 부등호를 사용해서 조회하는 것이 빠르다. 왜이럴까?
우선 구글링에 검색해보면 CPU Cycle일 것이라는 답변이 있다. 근데 최근 친절한 SQL 튜닝에서 이런 부분에 대해서 좀 세세하게 나온것이 있어서 확인해봤다.
물론 이게 정확한 예시가 아닐 수 있다. 정확하게 부등호만 나온 부분을 못찾았기에. 스캔 범위만 우선적으로 확인해봤다.
두 사진의 공통점은 범위 스캔하는 부분이 같다는 것이다. 어찌보면 당연하다. Explain 결과도 같으니까.
눈에 보이지 않은 내부적인 부분이라 생각한다. 그게 CPU Cycle때문이라는 것이다.
결과론적으로는 Between 보다는 Where 부등호가 좀 더 좋은 선택지라는 것이다. 그리고 그 이유는 CPU Cycle이라는 확신을 내리지 못하는 답이다. 이부분에 대해서는 좀더 찾아보고 포스팅을 좀 더 추가를 해야할 것같다. 그래도 값진 경험인 것은 직접 더미데이터를 만들었으며, Explain을 통해 결과를 확인했고 CPU Cycle이라는 결과가 정말 맞는지 직접 책을 찾아보고 Scan 범위를 확인했다는 점에서 이미 나는 점차 성장하고 있다는 것을 느끼며 마무리한다.