본문 바로가기

HWK블로그143

결재 검증 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.
Covering Index (커버링 인덱스) 1️⃣ Covering Index란?쿼리에 필요한 모든 컬럼이인덱스 안에 이미 들어 있어서테이블을 아예 읽지 않아도 되는 상태즉,인덱스 탐색 ✔테이블(Row) 접근 ❌2️⃣ 왜 테이블 접근이 그렇게 비싼가?InnoDB 기준으로 보면:인덱스(B+Tree) → PK 값만 있음실제 데이터는 → Clustered Index(테이블) 에 있음그래서 보통 쿼리는:인덱스 탐색 → PK 추출 → 테이블에서 PK로 다시 조회 (Random I/O)Covering Index는 두번째 단계를 완전히 제거한다. 3️⃣ 예제❌ 일반 인덱스-- 인덱스(COMPCD, PLCBUS, YEARXX, DOCSEQ)-- 쿼리SELECT *FROM HERGMTWHERE COMPCD = ? AND PLCBUS = ? AND YEARX.. 2026. 1. 6.

티스토리툴바