SQL·테스트 데이터
긴 SQL 조건과 JOIN을 읽기 쉽게 정리하기
사용할 도구
로그의 긴 SQL을 보면 무엇을 가져오는지부터 묻습니다. 가로 스크롤은 괄호·JOIN 조건을 놓치기 쉽습니다. 포맷으로 구조·읽기 순서를 만들 수 있지만 정확한 실행을 보장하지 않으며 DB 연결·실행도 하지 않습니다.
가상 주문 쿼리를 절별로 나누기
PostgreSQL로 예시를 포맷하면 대문자 SELECT·FROM·LEFT JOIN·WHERE·ORDER BY를 찾기 쉬워집니다. 반환 열→시작 표→연결 표→남길 행→순서로 읽으세요. 가상 테이블이라 실제 DB에서 실행할 필요 없습니다.
select o.id,o.total,c.name from orders o left join customers c on c.id=o.customer_id where o.status='paid' and (o.total>=1000 or o.priority=true) order by o.id;원문을 보존해 비교하세요. 대문자·줄바꿈은 논리 수정이 아닙니다. 테이블·열 존재, 권한, 결과 행 수는 DB 문맥이 필요합니다. 포맷 성공은 의미 검증·실행 성공이 아닙니다.
AND·OR 범위 읽기
예시는 paid이면서1000이상 또는priority true입니다. 괄호를 빼면 일반 우선순위에서priority는 미결제도 포함될 수 있습니다. 포맷은 그룹을 보여줄 뿐 업무 의도는 모르니 소액 결제·고액 미결제·우선 미결제 가상 행으로 따져보세요.
JOIN ON과 WHERE를 따로 보세요. WHERE에서 오른쪽 값을 요구하면 LEFT JOIN 미일치 행이 빠질 수 있어 이름만으로 왼쪽 전부 보존이라 단정 못 합니다. 조건 이동은 의미 변경 가능하므로 포맷과 별도 쿼리 리뷰입니다.
방언 선택은 SQL 이전 변환이 아님
입력의 PostgreSQL·MySQL·SQLite 방언을 고르세요. MySQL을 PostgreSQL로 포맷해도 함수·타입·인용·날짜 동작이 번역되지 않습니다. 미지원 구문은 성공만 얻으려 바꾸지 말고 원래 DB·구문을 확인하세요.
로그에 시각·식별자·소요 시간이 붙으면 SQL 범위를 먼저 확인하고 리터럴 줄바꿈·따옴표를 장식으로 오해해 지우지 마세요. 인수가 따로 있으면 보기 좋은 완성 SQL을 손으로 합치기 전 대응부터 읽으세요.
같은 이름 인수가 두 번 나올 때
플레이스홀더 변환은 SQL·인수JSON을 따로 받습니다. :id 두 번은 PostgreSQL에서 둘 다$1, ?형식은 등장마다 인수가 필요해 값이 두 번입니다. SQL만 복사하고 이전 인수 순서를 그대로 두지 마세요.
SELECT * FROM users WHERE id = :id OR manager_id = :id
Arguments: {"id":7}
PostgreSQL: id = $1 OR manager_id = $1
Question: id = ? OR manager_id = ? → [7, 7]일반 문자열·주석과 인수를 구분하지만 전체 방언 파서는 아닙니다. PostgreSQL의 ?는 연산자도 되어 입력이 제한됩니다. 복잡한 특수 구문은 DB·드라이버 공식 문서도 확인하세요.
읽은 뒤 다음 조사 정하기
행이 많으면 조건·JOIN, 값이 틀리면 인수·NULL, 느리면 실행 계획·데이터를 봅니다. 포맷은 시간·인덱스·잠금을 측정하거나 속도 향상을 증명하지 않습니다. 조사 대상을 찾는 읽기 쉬운 문장을 제공합니다.
공유 시 개인정보·비밀 값을 가상 값으로 바꾸되 관련 구조를 유지하세요. DB 실행은 별도 승인 단계입니다. 절·괄호부터 읽고 인수 대응을 확인하면 실행 전 질문을 명확히 할 수 있습니다.
SQL이 읽히면 결과 행 수를 생각하기
JOIN이 보이면 주문 한 행에 반대쪽 몇 행이 대응하는지 생각하세요. 키가 유일하지 않으면 고객 한 명을 기대해도 행이 늘 수 있습니다. 정렬 도구는 스키마나 데이터를 읽지 않아 행 수를 검증하지 않습니다. DISTINCT로 숨기기 전에 행을 늘리는 관계를 확인하세요. 서식은 조사를 쉽게 할 뿐 끝내지는 않습니다.
LEFT JOIN의 NULL 가능 쪽에 WHERE 조건을 걸면 대응하지 않는 행이 빠질 수 있습니다. ON과 WHERE 사이의 이동은 서식 변경이 아닙니다. 읽기 쉬운 구조로 작은 가상 데이터의 기대 결과를 먼저 적으세요. 도구는 조건을 옮기거나 실행하지 않으며 데이터베이스 검증은 권한을 제한한 별도 작업입니다.
가독성이 성능을 보장하지는 않습니다. 인덱스, 행 수, 통계, 실행 계획은 입력하지 않았습니다. 서식 변경과 결과를 유지한 성능 개선을 나누어 보고하세요. 후자는 해당 DB의 계획과 실측이 필요합니다. 키워드 대문자나 줄바꿈은 성능 근거가 아닙니다.