현재 DB 스터디의 일환으로 '친절한 SQL 튜닝'을 한번 더 읽고 있다. 이번 파트는 소트 머지 조인 + 해시 조인 인데, 개인적으로 해당 서적을 이미 1회독한 상황이라 두 조인이 대략적으로 어떻게 작동하고, 어떤 상황에서 활용되는지는 이해하고 있다. 다만 1회독 시 잘 몰라서 그냥 넘어갔던 오라클의 PGA와 SGA의 개념이 있는데, 이번 기회에 이를 공부하고 넘어가면 좋겠다 싶어 공부한 내용들을 기록해두기 위해 이 글을 작성한다. 이 글에서는 책에서 간단하게 다뤄진 데이터 조회 시 SGA와 PGA 접근의 속도 차이에 중점을 두고 다뤄보려한다. 각 메모리 공간에 대한 소개 SGA SGA란 System Global Area의 약자로, DB 내 하나만 존재하면서 모든 세션이 공유하는 메모리 공간이다. SG..

Q. 역정규화를 수행하는 이유가 무엇인가요? A. 테이블이 쪼개져 조인 연산이 쿼리 내 포함되면 성능이 안좋아지기 때문에, 조회 성능을 개선하기 위해서 역정규화를 고려할 수 있습니다. 최근 면접 스터디 중, 역정규화에 대해 이야기를 하다가 나온 문답이다. 질문은 내가, 답변은 스터디원이 해주셨는데 만약 서로 입장이 바뀌었어도 똑같이 대답했을 것 같다. Database를 공부하면서, 혹은 개발을 진행하면서 통념처럼 받아들이게 되는 말이 바로 조인은 느리다.이다. 그런데 최근에 들어서는 Database에 대해 더 깊게 공부할 일들이 생기면서 이에 의문이 생겼다. 조인이 만약 진짜 느린거라면, 왜 그런건데? 보통 이렇게 까지 물어보면 테이블 여러개를 봐야하니까.라고 답변이 돌아오는데 이런 대답은 내가 원하는 ..

다양한 데이터의 접근 형태에 일일이 대응하여 인덱스를 많이 만들 수 있는 환경이라면 인덱스 생성에 있어 고민의 여지가 적겠지만, 아쉽게도 인덱스가 많아지면 많아질수록 그에 따른 사이드 이펙트(DML 성능 저하, 저장 공간 차지)가 존재한다. 따라서 적은 수의 인덱스를 유지하는 동시에 다양한 데이터 접근 형태에 대해 인덱스 스캔을 지원하는 것은 중요하다. 이를 위해서는 복합 인덱스 기반으로 하나의 인덱스가 여러 상황을 커버할 수 있도록 테이블 설계가 이루어져야 한다. 해당 글에서는 이를 돕기 위해 복합 인덱스가 어떤 방식으로 작동하는지 알아보고, 복합 인덱스가 작동하는 경우의 수에 대해 다뤄보려고 한다. 이 글은 Mysql 기준으로 작성되었다. 복합 인덱스 작동 방식 복합 인덱스는 둘 이상의 칼럼을 통해 ..

얼마 전 SQL 쿼리를 작성하다가 문득 문자열 칼럼에 퍼센트(%) 기호없이 LIKE를 쓰는 것과 곧바로 등호 연산자를 쓰는 것에 어떤 차이가 있는지 의문이 생겼다. 다만 이를 곧바로 해결하지 않았다가 잊고 있었는데, 스터디를 위해 책을 읽다가 LIKE 연산자를 사용할 때와 등호 연산자를 사용할 때 내부적인 작동 방식이 차이가 있는 것으로 생각되어 이를 정리하고자 이 글을 작성한다. 해당 문서는 Mysql을 기준으로 작성되었으며, 다른 DB의 경우 다르게 작동할 여지가 있습니다. LIKE vs Equal(=) LIKE를 사용할 경우 와일드카드의 도움을 받아서 더 자유로운 방식의 문자열 비교가 가능하다는 것은 대부분이 아는 사실이니 넘어가도록 하자. (Equal에서는 와일드카드들도 전부 비교 문자열의 일부로..

느린 쿼리를 개선하는 것은 사용자의 입장에서도 중요하지만 DB 레벨의 효율적 자원관리를 위해서도 꼭 필요한 일이다. 어떻게 쿼리의 실행 시간들을 확인할 수 있을까? 직접 일일이 실행시켜보면서 시간을 재야 하나? 다행히도 일부 DB들은 그들 서버에서 수행되는 쿼리 중 서버에 악영향을 미칠 수 있는 Slow Query(슬로우 쿼리)들을 따로 저장해두고, 이를 개발자들이 확인할 수 있도록 하고 있다. 이 글에서는 슬로우 쿼리의 확인이 용이한 두 DB, Mysql과 Postgresql에서 이를 설정하고 확인하는 법을 다루려고 한다. Mysql 설정법 Mysql에서는 아래 내용을 my.cnf에 추가하면 1초 이상 걸리는 쿼리를 슬로우 쿼리로 상정하고 이에 대한 수집이 시작된다. 물론 설정 파일을 수정했기 때문에 ..

일반적으로 Index Scan이라고 불리우는 기법들(Index Range Scan, Index Unique Scan 등)은 Single Block IO를 활용한다. (해당 내용에 대한 이해도가 부족하다면 이전 글 참조 -> 테이블 스캔 방식에 따른 DB Block IO 전략) 뒤에 설명하겠지만, 읽어야 할 블록이 버퍼에 존재한다고 해도 해당 블록에 접근하기 위한 메모리 상의 포인터를 획득하는 과정이 필요하다. 따라서 읽어야 할 인덱스 레코드가 많은 경우엔, 그 수 만큼 논리적 IO가 발생한다고 볼 수 있고 매번 포인터를 새롭게 획득한다고 생각할 수 있다. 만약 인덱스 리프 노드에서 읽어낸 테이블 ROWID가 대부분 동일한 블록을 가리키고 있다면? 그럼에도 불구하고 인덱스 레코드 수 만큼 포인터 획득 과정..