◈ Refactoring/쿼리 튜닝일지🔧

[튜닝일지] 5. 쿼리문 조건에도 순서가 있다? [백엔드 개발자의 쿼리 튜닝일지]

5. 쿼리문 조건에도 순서가 있다? SQL 쿼리를 작성할 때, join이나 where 절에 들어가는 조건문의 순서는 중요한 역할을 한다. 가장 엄격한 필터링 조건을 먼저 배치하여 행을 최대한 빨리 필터링하면 나머지 조건에 대해 평가할 행 수가 줄어들어 성능이 향상되며, 이는 데이터베이스 시스템의 옵티마이저가 최적의 실행 계획을 수립하는 데 도움이 된다. 조건문의 효율 순위는 주로 데이터베이스의 인덱스 및 데이터 분포에 따라 다를 수 있으나 인덱스를 타는 여부로만 고려할 때, 조건문의 효율 순위는 다음과 같다. 동등 비교: 동등 비교는 일반적으로 인덱스를 가장 잘 활용할 수 있는 조건이다. 특정 컬럼에 대한 동등한 값을 비교하는 경우에는 인덱스를 타고 해당 값과 일치하는 행을 빠르게 찾을 수 있다. 날짜 ..

[튜닝일지] 4. 숫자 ID vs 텍스트 ID [백엔드 개발자의 쿼리 튜닝일지]

4. 숫자 ID vs 텍스트 ID사이드 프로젝트를 준비하면서 고민한 ID 타입에 대한 공부와 고찰을 남겨보려 한다.1) 숫자 ID [ ex) 3451832 ]- 장점숫자는 일반적으로 텍스트보다 작은 공간을 차지하기 때문에 인덱스 생성 및 검색이 빠르다.데이터베이스에서 숫자 인덱스를 사용하면 메모리 사용량을 줄일 수 있다.자동 증가(Auto-increment)와 같은 기능을 이용하여 쉽게 새로운 ID를 생성할 수 있다.- 단점가독성이 떨어질 수 있다. 숫자 ID는 사용자에게 의미 있는 정보를 전달하지 않는다.데이터베이스에서 무작위로 할당된 ID를 사용할 경우, 보안상의 문제가 발생할 수 있다.2) 텍스트 ID [ ex) user123 ]- 장점가독성이 좋다. 텍스트 ID는 해당 사용자를 직관적으로 나타낸다..

[튜닝일지] 3. 믿었던 Function이 날 배신했다. [백엔드 개발자의 쿼리 튜닝일지]

3. 믿었던 Function이 날 배신했다. 지난 쿼리 튜닝으로 기존 대비 절반 이상으로 실행 속도를 절감시켰다. 그러나 여기서 튜닝을 멈추지 않았다. 아니 멈출 수 없었다. 이번에 건드린 건 Function(≒Procedure, 프로시저)였다. Function을 주석하고 실행하면 신기하게도 실행 속도가 빨라졌다. 왜 그런 것일까요? GPT 선생님께 여쭤보았습니다. 더보기 MySQL에서 함수가 인덱스를 사용하는지 여부는 함수의 형태와 쿼리의 구성에 따라 다릅니다. 일반적으로, MySQL은 함수를 사용하여 쿼리를 실행할 때 인덱스를 사용하지 않습니다. 함수는 쿼리에서 조건절에 사용되는 경우 인덱스를 사용할 수 있는 기회를 제한합니다. 예를 들어, 다음과 같은 쿼리에서는 인덱스를 사용할 수 없습니다. SEL..

[튜닝일지] 2. JOIN, 잘 좀 만나봅시다. (feat. or 조건) [백엔드 개발자의 쿼리 튜닝일지]

[튜닝일지] 1. 인덱스, 너 잘 타고 있니? [백엔드 개발자의 쿼리 튜닝일지] 1. 인덱스, 너 잘 타고 있니? 이번에 담당하게 된 프로젝트가 있는데 사이트 로딩 속도가 매우 느렸다. 아래와 같이 쿼리 조회 자체가 안되는 경우도 많아서 쿼리부터 개선 해보자는 마음으로 시 yermi.tistory.com 2. JOIN, 잘 좀 만나봅시다. (feat. or 조건) 지난 번에는 인덱스를 태우기 위해 특정 컬럼을 서브쿼리로 변경하였다. 이번 쿼리는 실행속도가 약 5초 정도 걸렸으나, 이전 인덱스 작업을 한 view를 참조하고 있었기에 3초 중반 정도로 개선이 되었다. 이번에는 이 쿼리를 1초 중반대로 줄여볼 예정이다. EXPLAIN으로 성능검사를 해보니, rfd라는 테이블이 인덱스를 안타고 있었다. or 조..

[튜닝일지] 1. Index, 너 잘 타고 있니? [백엔드 개발자의 쿼리 튜닝일지]

1. Index, 너 잘 타고 있니? 이번에 담당하게 된 프로젝트가 있는데 사이트 로딩 속도가 매우 느렸다. 아래와 같이 쿼리 조회 자체가 안되는 경우도 많아서 쿼리부터 개선 해보자는 마음으로 시작했다. (웹에서도 관련 기능이 당연히 동작 안하는데, 고객사는 안되는 거라 생각하고 못쓰고 있었다고 한다..😂😂) 소스를 분석하면서 view에서 실행속도가 느리다는 걸 파악했다. view가 view를 join하고 중첩하여 참조하다보니 실행 속도가 배로 느려진 것.. (이 중 300초 초과되는 검색과 관련된 view는 특정 view를 3번에 걸쳐 참조하고 있었다.) 보안 상의 이유로 view 이름을 공개할 수는 없지만, 위에 표에서 노란색으로 되어 있는 view는 성능이 낮은 모든 view에서 참조하고 있었다. ..