CS/SQL9 HASH JOIN Hash Join을 고려해야 했던 이유— 데이터는 적은데 왜 이렇게 느릴까?1. 문제 상황구조가 동일한 두 테이블 A, B가 있었다.둘 다 문서정보 테이블과 INNER JOIN인덱스는 유효하지 않음A는 데이터가 많음B는 데이터가 4건뿐그런데 결과는 의외였다.A는 빠름B는 8초 소요데이터가 적은 B가 훨씬 느렸다.2. 원인: Join 방식의 차이INNER JOIN은 논리적 조인이고실제 물리적 실행 방식은 다음 중 하나가 선택된다.Nested LoopHash JoinMerge Join옵티마이저는 비용 계산 후 자동으로 결정한다.B가 느렸던 이유B는 데이터가 적었기 때문에옵티마이저가 Nested Loop를 선택했을 가능성이 크다.Nested Loop는 다음과 같이 동작한다.Outer 테이블 1건→ Inner .. 2026. 2. 25. 결재 검증 SQL의 실행 흐름 개선 (EXISTS, Short-Circuit 적용) 📌 업무 배경공통된 컬럼을 사용하는 12개의 업무 테이블이 존재테이블: APP_A_MST ~ APP_L_MST공통컬럼: doc_id, biz_year, biz_quarter, biz_round각 업무 결재가 완료되면, 다른 업무들의 상태가 결재완료인지 조회, 다음 과정을 수행하는데 필요한 데이터를 생성해야 함결재가 완료시 결재문서의 doc_id가 반환됨특정 문서(doc_id)가 어느 테이블에 속해 있는지 모름해당 문서가 속한 연도 / 분기 / 차수를 기준으로👉 모든 업무 테이블에서 결재 완료 상태인지 검증APP_A_MST ~ APP_L_MST 가 아닌, 하나의 테이블을 사용하면 좋겠지만, 그럴 수 없는 상황1️⃣ 1차 버전 – UNION ALL 기반 전체 스캔🔧 접근 방식Dynamic SQL을 사용.. 2026. 2. 3. MSSQL - 행마다 새로운 시퀀스 부여 1️⃣ 업무 요청특정 페이지를 그대로 복제할 수 있도록 해달라는 요청을 받았다.해당 페이지에는 여러 개의 테이블이 존재하고, 그중 일부 테이블은 각 행마다 고유한 ID를 가지는 구조로 되어 있다.기존 페이지에서는 + 버튼을 통해 행을 하나씩 추가하며,이때마다 ID를 개별적으로 채번하는 방식을 사용하고 있었다.하지만 페이지 전체를 복제하는 기능에서는 상황이 달라진다.한 번의 동작으로 n개의 행을 조회하고, 각 행마다 새로운 ID를 부여해야 하기 때문이다.만약 기존 방식처럼 행을 하나씩 추가하며 ID를 채번한다면,통신 횟수가 급격히 증가하고, 결과적으로 페이지 복제 속도와 사용감이 크게 저하될 가능성이 있다.이런 문제를 해결하기 위해,복제 대상 데이터를 한 번에 조회한 뒤, 서버 단에서 각 행에 새로운 ID.. 2026. 1. 28. Index Merge 1️⃣ Index Merge란?Index Merge는 MySQL/MariaDB 옵티마이저가:“단일 인덱스로는 최적화가 안 되니까여러 인덱스를 각각 타서결과를 합쳐보자”라고 판단했을 때 선택하는 실행 계획이다.EXPLAIN에 보통 이렇게 나타난다.type: index_mergeExtra: Using intersect(...)2️⃣ 옵티마이저가 Index Merge를 선택하는 상황테이블에 이런 인덱스가 있을 때-- 인덱스IDX_A (COMPCD)IDX_B (YEARXX)-- 쿼리WHERE COMPCD = ? AND YEARXX = ?단일 복합 인덱스 ❌두 개의 단일 인덱스만 존재👉 옵티마이저는:COMPCD 인덱스 스캔YEARXX 인덱스 스캔두 결과의 교집합 계산3️⃣ 왜 느린가? (핵심 이유 5가지)① .. 2026. 1. 6. 이전 1 2 3 다음