갴발자 디찌 갴발자 디찌

메인 쿼리의 결과 개수만큼 서브 쿼리가 실행되는 경우는 **상관 서브쿼리(Correlated Subquery)**일 때 주로 발생합니다. 상관 서브쿼리는 메인 쿼리의 각 행에 대해 서브쿼리가 반복적으로 실행되는 구조를 가지므로, 메인 쿼리의 결과가 많아질수록 서브쿼리 실행 횟수도 그만큼 늘어납니다. 1. 상관 서브쿼리 (Correlated Subquery)상관 서브쿼리는 메인 쿼리의 각 행에 의존해서 값을 계산하는 쿼리입니다. 예를 들어, 아래와 같은 쿼리가 있습니다: SELECT a.id, (SELECT COUNT(*) FROM orders o WHERE o.user_id = a.id) AS order_countFROM users a; 이 경우 users 테이블의 각 행마다 orders ..

PostgreSQL의 EXPLAIN ANALYZE 결과에서 조인 과정 중 필터링된 레코드 수를 나타내는 항목입니다. 이는 조인 필터가 어떤 역할을 하는지를 보여주는 부분으로, 조인을 수행할 때 특정 조건을 만족하지 않아 제외된 레코드들의 수를 의미합니다.1. Join Filter란?Join Filter는 조인할 때 조인 조건 외에 추가적으로 필터링을 적용하는 조건을 의미합니다. 조인 시 두 테이블에서 조인 조건을 만족하는지 여부를 평가한 뒤, 그 조건 외의 추가 조건에 따라 데이터를 더 걸러낼 수 있습니다.조인 조건: 테이블 간의 관계를 설정하는 기본 조건입니다. 예를 들어 ON a.id = b.a_id는 두 테이블을 연결하는 조인 조건입니다.조인 필터: 조인 후에 추가로 레코드를 걸러내는 조건입니다. ..

겉으로 보기에는 두 경우 모두 비교 연산이 같은 수(100,000번)처럼 보이지만, 실제로는 성능 차이가 발생할 수 있습니다. 그 이유는 드라이빙 테이블이 먼저 읽힌 이후, 드리븐 테이블에서 데이터를 검색하는 방식과 그 과정에서의 인덱스 사용 여부에 있기 때문입니다. 이를 좀 더 자세히 설명해볼게요.1. Nested Loop Join의 실행 방식드라이빙 테이블: 조인 시 먼저 읽히는 테이블로, 바깥쪽 루프의 역할을 합니다.드리븐 테이블: 드라이빙 테이블의 각 레코드에 대해 조회를 수행하는 테이블로, 안쪽 루프에서 사용됩니다.2. 두 경우의 차이점두 가지 케이스를 다시 살펴볼게요:케이스 1: 드라이빙 테이블이 100개, 드리븐 테이블이 1,000개인 경우.드라이빙 테이블에서 100개의 레코드를 순차적으로 ..

*MySQL (특히 InnoDB)**와 PostgreSQL는 행 잠금과 쓰기 락 처리 방식에서 차이가 있습니다. MySQL과 PostgreSQL은 모두 **MVCC (Multi-Version Concurrency Control)**를 사용하여 데이터의 일관성을 유지하면서 동시성을 처리하지만, 행 잠금(ROW-level locking) 방식에 차이가 있습니다.MySQL (InnoDB)에서의 행 잠금InnoDB는 인덱스를 사용한 쿼리에 대해 인덱스 기반의 잠금을 사용합니다. 즉, 특정 인덱스를 통해 WHERE 절에 의해 필터링된 모든 행에 잠금이 걸리며, 이 잠금은 다음과 같은 특성을 가집니다:인덱스 기반 락: InnoDB는 인덱스를 사용하는 쿼리에 대해 잠금을 걸기 때문에, 해당 인덱스를 사용하는 범위 내..

**FSM (Free Space Map)**은 PostgreSQL에서 테이블 및 인덱스의 사용되지 않은 공간을 추적하기 위한 데이터 구조입니다. FSM은 디스크 페이지 내에서 아직 사용 가능한 여유 공간을 기록하며, 데이터베이스 성능을 최적화하는 데 중요한 역할을 합니다.FSM의 역할빈 공간 관리: PostgreSQL의 테이블에 새로운 데이터를 삽입하거나 기존 데이터를 수정할 때, 새롭게 할당된 디스크 페이지 대신 기존의 빈 공간을 활용하는 것이 효율적입니다. FSM은 테이블 내에서 사용되지 않은 공간(빈 페이지 또는 일부 공간이 사용 중인 페이지)을 추적하여, 필요할 때 이 빈 공간을 사용할 수 있게 도와줍니다.데이터 삽입 효율성: 새로운 데이터가 삽입될 때, PostgreSQL은 FSM을 참고하여 빈..

1. GROUP BY데이터를 그룹화하여 각 그룹당 하나의 결과를 반환합니다.그룹화된 각 결과에 대해 집계 함수(SUM, AVG, COUNT 등)가 적용됩니다.GROUP BY를 사용하면 데이터가 그룹별로 집계되어, 원래의 개별 행을 유지하지 않습니다.예시:SELECT department_id, COUNT(*) AS employee_countFROM employeesGROUP BY department_id; 설명:department_id별로 그룹화하고, 각 부서의 직원 수를 계산합니다.결과에는 각 부서당 하나의 행만 남습니다. (즉, department_id별로 집계된 결과만 표시)2. PARTITION BY데이터를 특정 기준으로 나누지만, 데이터의 원래 행은 유지합니다.주로 윈도우 함수(ROW_NUMBER..

Redis Sentinel은 Redis 클러스터의 고가용성을 보장하기 위해 사용하는 시스템입니다. Redis Sentinel은 Redis 인스턴스의 모니터링, 장애 감지, 자동 장애 조치(failover) 및 클러스터의 구성을 관리하는 역할을 합니다. 이를 통해 Redis 서버에 문제가 발생했을 때, Sentinel이 이를 감지하고 자동으로 마스터 Redis 인스턴스를 교체하여 서비스 중단을 최소화할 수 있습니다.Redis Sentinel의 주요 기능:모니터링: Sentinel은 Redis 마스터와 슬레이브 인스턴스를 지속적으로 모니터링하여 인스턴스가 정상적으로 동작하는지 확인합니다.장애 감지: 마스터가 응답하지 않을 경우, Sentinel은 이를 감지하고 해당 인스턴스를 장애 상태로 판단합니다.자동 장..

MyBatis와 같은 ORM 툴을 사용할 때, 동일한 데이터를 가져오기 위해 5번의 쿼리를 호출하는 것과 5개의 쿼리를 WITH 구문을 통해 하나의 쿼리로 요청하는 것 사이에는 성능상의 차이가 있습니다. 이 차이가 발생하는 이유는 여러 가지가 있지만, 주요 원인은 다음과 같습니다:  네트워크 레이턴시:각 쿼리 호출 시마다 네트워크 요청이 발생합니다. 네트워크 왕복 시간이 누적되면 지연이 발생할 수 있습니다. 커넥션 풀을 사용해도 각 요청마다 네트워크 레이턴시가 존재하기 때문에, 5번의 네트워크 왕복 시간이 1번의 왕복 시간보다 더 큽니다.쿼리 실행 준비:각 쿼리 호출 시마다 데이터베이스는 쿼리 파싱, 최적화, 실행 계획 수립 단계를 거쳐야 합니다. 5번의 쿼리 호출은 이 단계를 5번 반복하는 셈이 됩니다..