[데이터베이스] 인덱스(index) 정리인덱스 목차, 색인, 책갈피와 같은 기능을 하는 인덱스는, 데이터베이스 분야에서는 어떤 데이터를 검색할 때 속도를 높여주는 자료 구조로메모리 영역에 생성되는 일종의 책갈피이다. mag1c.tistory.com 위 글의 복합 인덱스를 통한 튜닝 부분을 따로 옮긴 포스팅입니다. 분명 일정한 기준이 있을 텐데 왜 얘기들이 조금씩 다른 것일까? DB의 버전 때문일까 옵티마이저가 무조건적으로 100% 맞다는 보장이 없어서일까? 잘 모르겠다. 그래서 직접 쿼리 튜닝의 경험들을 복기하며 복합 인덱스를 생성할 때에는 어떤 순서로 인덱스를 구성해야 하는지 알아보았다. 서비스 내부에는 모든 유저의 장바구니(앞으로 견적함이라 부름)를 볼 수 있는 기능이 존재하는데 업종으로 필터링할 경..

인덱스   목차, 색인, 책갈피와 같은 기능을 하는 인덱스는, 데이터베이스 분야에서는 어떤 데이터를 검색할 때 속도를 높여주는 자료 구조로메모리 영역에 생성되는 일종의 책갈피이다.    인덱스 구조보통 Hash, B-Tree, B+Tree가 있다. Hash우리가 알고있는 Key, Value형태의 자료 구조다.해시 함수로 키 값을 해시값으로 변환하고, 이 해시 값을 기반으로 데이터를 빠르게 조회할 수 있다. - O(1)   하지만 이런 해시구조의 특성상 범위 검색에 효율이 떨어진다. 키 값이 조금이라도 변하게 되면 완전히 다른 해시 값을 반환하기 때문이다.범위 검색에서의 부등호 연산을 포함한 범위 조건(BETWEEN, LIKE 등)에는 적합하지 않다.   B-TreeB-Tree는 이진 트리를 확장한 트리 ..

해당 글을 보고 오시면 좋아요  [쿼리튜닝] 신입 개발자의 간단한 사내 조회 쿼리의 쿼리튜닝 여정.발단 계속해서 짧은 주기로 프로젝트를 쏟아내고 있던 와중에 DB연산이 많은 작업을 수행하는 경우가 생겼다. 개발 단계에서 API 자체를 돌리는 과정에서도 1~2000ms가 되어 걱정하고 있던 과정에 Qmag1c.tistory.com     서론팀장님께서 나를 불렀다."집계 함수를 사용해서 요청사항 집계를 하는 SQL문이 있는데 ~~~ 성능 최적화를 좀 할 수 있을까요?" 기존 쿼리를 받아들고 돌려보았다.    기존 상태SELECT    YEAR(a.registe_time) AS year,    MONTH(a.registe_time) AS month,    a.code,    count(a.code) AS t..

발단계속해서 짧은 주기로 프로젝트를 쏟아내고 있던 와중에 DB연산이 많은 작업을 수행하는 경우가 생겼다.개발 단계에서 API 자체를 돌리는 과정에서도 1~2000ms가 되어 걱정하고 있던 과정에QA를 진행했더니 난리가났다.이상하게 이에 대해 아무도 피드백을 해 주지 않았다.  들쭉날쭉한 건 요청이 한번에 서버로 몰릴 때로 인식을 하겠다지만,30건 정도밖에 안되는 데이터를 연산하는데 말이 안된다고 생각했고, 작업에 들어갔다.  원인 파악하기 원인을 파악하기 위해, 어쩔 수 없이 로직의 각 구간별로 로깅을 시도했다.  연산 처리속도는 빨랐는데, 애초에 데이터를 그렇게 많이 들고나오지 않기 때문이다.연산은 간략히 설명하자면 다음과 같다 데이터를 row형태로 가져나오는데, PK가 일치할 경우, 같은 문의에 상품..