조인 종류와 뷰

조건이 없으므로 두 테이블 행수의 곱입니다. A 가 10행, B 가 5행이면 50행입니다.

실무에서 의도적으로 쓰는 경우는 드뭅니다. 대개 조인 조건을 빠뜨린 실수로 나타납니다. 10만 행과 10만 행이면 100억 행이라 쿼리가 끝나지 않고 디스크와 메모리를 소진합니다.

의도해서 쓰는 곳도 있습니다.

흔한 실수: LEFT JOIN 이 왼쪽 행수를 그대로 유지한다고 생각하는 것. 오른쪽에 여러 행이 맞으면 왼쪽 행이 그만큼 복제되어 늘어납니다.

"뷰가 성능을 향상시킨다"가 사실이 아닙니다. 뷰는 저장된 쿼리이고 결과를 저장하지 않습니다.

뷰를 조회하면 그 안의 쿼리가 그때 실행됩니다. 느린 쿼리를 뷰로 감싸면 여전히 느립니다. 오히려 느린 것을 감춰서 원인을 찾기 어려워지는 부작용이 있습니다.

결과를 저장하려면 구체화된 뷰를 써야 하고, 그러면 갱신 시점을 관리해야 합니다. 그것은 실질적으로 집계 테이블을 두는 것과 같습니다.

흔한 실수: 뷰를 여러 겹으로 쌓는 것. 뷰가 뷰를 참조하고 그것이 또 뷰를 참조하면, 실행 계획이 예측하기 어려워지고 불필요한 조인이 실행됩니다.

한 행이 여러 행과 맞으면 원본 행이 복제되어 합계가 늘어납니다.

주문 1건(금액 10,000)에 주문상품 3건이 있는 경우입니다.

세 번째는 함정입니다. 금액이 우연히 같은 두 주문이 있으면 하나로 세어 결과가 틀어집니다.

네 번째가 근본입니다. 조인하기 전에 어느 쪽이 일대다인지 알면 부풀려지는 것을 예상할 수 있습니다.

흔한 실수: 행수만 보고 정상이라 판단하는 것. 일대일 조인이라도 원본에 중복이 있으면 늘어납니다. 조인 키에 유일 제약이 있는지 확인해야 합니다.

조인 자체로는 줄지 않지만, WHERE 절에 오른쪽 테이블 조건을 걸면 줄어듭니다.

두 번째가 사실상 INNER JOIN 이 됩니다. LEFT JOIN 을 썼는데 결과가 왼쪽보다 적으면 이 경우를 의심합니다.

차이는 조건이 언제 적용되는지입니다.

NULL 을 허용하려면 WHERE b.status='X' OR b.a_id IS NULL 처럼 명시해야 합니다.

흔한 실수: 필터를 습관적으로 WHERE 에 쓰는 것. INNER JOIN 에서는 ON 과 WHERE 가 같은 결과를 주지만, OUTER JOIN 에서는 완전히 다릅니다.