SQL 조회 — SELECT · JOIN · 서브쿼리 · 집계 E08

답 — SELECT 과목이름, MIN(점수) AS 최소점수, MAX(점수) AS 최대점수 FROM 성적 GROUP BY 과목이름 HAVING AVG(점수) >= 90;

원리 — "과목이름별"이라는 말이 나오면 GROUP BY 과목이름 이다. 같은 과목의 행을 한 묶음으로 접고, 묶음마다 MIN · MAX · AVG 같은 집계를 낸다. 묶음에 조건을 거는 자리는 WHERE 가 아니라 HAVING 이다 — WHERE 는 묶기 전 행 하나하나에, HAVING 은 묶은 뒤 집계값에 건다. "평균이 90 이상인 과목만"은 묶은 뒤의 조건이라 HAVING AVG(점수) >= 90 이다. AS 는 결과 열의 이름표(별칭)를 붙인다.

따라가기

1. 무엇을 뽑나 → 과목이름, 최소, 최대 → SELECT 과목이름, MIN(점수) AS 최소점수, MAX(점수) AS 최대점수
2. 어디서 → FROM 성적
3. 무엇별로 → GROUP BY 과목이름
4. 묶음 조건 → HAVING AVG(점수) >= 90

헷갈리는 자리 — HAVING 자리에 WHERE AVG(점수) >= 90 을 쓰는 것. WHERE 안에는 집계 함수를 못 쓴다(오류). 별칭 이름을 문제가 준 그대로(최소점수 · 최대점수) 적어야 하고, "이상"은 >= 다(> 는 초과). GROUP BY 에 없는 열을 SELECT 에 넣으면 안 된다는 규칙도 같이 기억한다.

답의 SQL 을 sqlite 3.49 에서 실행해 결과를 확인했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 문장 · 열 이름이 실제와 다를 수 있다.

답 — 열 A 에 4 / 3 / 2 / 1 네 행. UNION 은 중복을 지우고, DESC 는 큰 값부터다.

원리 — UNION 은 두 SELECT 의 결과를 위아래로 이어 붙이되 같은 행은 하나만 남긴다(집합의 합집합). 중복까지 다 남기려면 UNION ALL 이다. T1 의 3 이 두 번 있어도 하나로 접히고, T2 의 2 는 T1 에도 있으니 하나만 남는다. ORDER BY A DESC 는 합친 결과 전체를 A 기준 내림차순으로 정렬한다 — 정렬은 마지막에 한 번만 걸린다.

따라가기

1. T1: 1, 2, 3, 3 → T2: 2, 4
2. UNION → {1, 2, 3, 4} (3 중복 · 2 중복 제거)
3. DESC → 4, 3, 2, 1 (한 열 A, 네 행)

헷갈리는 자리 — 3 을 두 번, 2 를 두 번 남겨 여섯 행으로 적는 것(UNION ALL 의 결과). DESC 를 오름차순으로 읽어 1 2 3 4 로 적는 것. 답을 표 꼴로 요구하면 열 이름 A 까지 적는다. UNION 을 쓰려면 두 SELECT 의 열 수와 자료형이 같아야 한다는 것도 같은 묶음의 규칙이다.

표를 sqlite 3.49 에 넣고 같은 SQL 을 실행해 결과를 확인했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 표 · 값이 실제와 다를 수 있다.

답 — 열 B 에 a / b 두 행. 안쪽 SELECT 가 A ≤ 2 인 A 값 {1, 2} 를 만들고, 바깥은 A 가 그 안에 있는 행의 B 를 뽑는다.

원리 — 괄호 안 SELECT(서브쿼리)가 먼저 계산돼 값의 목록이 되고, A IN (목록) 은 "A 가 목록 중 하나와 같다"는 조건이다. 안쪽이 같은 테이블을 읽어도 상관없다 — 먼저 목록을 만들고 그다음 바깥이 그 목록으로 거른다고 두 단계로 읽으면 된다. 결과 열은 SELECT 뒤의 B 하나뿐이다.

따라가기

1. 안쪽: A <= 2 인 행 → A = 1, 2 → 목록 (1, 2)
2. 바깥: A IN (1, 2) 인 행 → 첫째 · 둘째 행
3. 그 행들의 B → a, b

헷갈리는 자리 — 안쪽 SELECT 가 A 를 뽑는다고 답에 A 값 1, 2 를 적는 것. 결과 열은 바깥 SELECT 의 B 다. 조건이 < 2 였다면 a 한 행뿐이다 — 등호를 본다. IN 대신 = (SELECT …) 를 쓰면 서브쿼리가 두 행을 돌려줘 오류가 난다 — 여러 값에는 IN 이다.

표를 sqlite 3.49 에 넣고 같은 SQL 을 실행해 결과를 확인했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 표 · 값이 실제와 다를 수 있다.

답 — 1. AND 가 OR 보다 먼저 묶이므로 "(KIND = 'A' 이고 SCORE ≥ 80) 또는 KIND = 'C'" 이고, 앞 조건은 없고 뒤 조건은 한 행이다.

원리 — SQL 에서 AND 는 OR 보다 우선순위가 높다. 괄호가 없으면 a AND b OR c 는 (a AND b) OR c 로 읽는다. 그래서 이 조건은 "A 이면서 80점 이상"인 행과 "C 인 행" 둘을 합친 것이다. A 의 점수는 70 과 50 이라 앞쪽은 0 행, C 는 4번 행 하나다. COUNT(*) 는 조건을 통과한 행 수다.

따라가기

1. KIND = 'A' AND SCORE >= 80 → A 는 70 · 50 → 0 행
2. OR KIND = 'C' → 4번 행 → 1 행
3. COUNT(*) → 1

헷갈리는 자리 — 왼쪽부터 묶어 KIND = 'A' AND (SCORE >= 80 OR KIND = 'C') 로 읽으면 0 행이 된다. 반대로 괄호를 (… OR KIND = 'C') 에 넣어 3 행으로 세는 것도 오답이다. AND 먼저, 그다음 OR — 이 우선순위 하나를 묻는 문제다.

표를 sqlite 3.49 에 넣고 같은 SQL 을 실행해 결과를 확인했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 표 · 값이 실제와 다를 수 있다.

답 — 1. 인원이 2 명 미만인 프로젝트는 20(Beta)뿐이고, 그 프로젝트에 속한 직원은 Charlie 한 명이다.

원리 — 서브쿼리가 세 겹이면 가장 안쪽부터 값을 만들어 바깥으로 올린다. 가장 안쪽은 employee 를 project_id 별로 묶어(GROUP BY) 인원이 2 명 미만인(HAVING COUNT(*) < 2) project_id 를 고른다. 가운데는 그 id 의 프로젝트 이름을 뽑는다. 바깥은 employee 와 project 를 project_id 로 이어 붙인(JOIN … ON) 뒤 이름이 그 목록에 있는 행만 센다. 각 층의 결과를 표로 적어 두면 헷갈리지 않는다.

따라가기

1. 안쪽: 10 → 2명, 20 → 1명, 30 → 2명 → COUNT < 2 인 것은 20
2. 가운데: project_id 20 의 name → Beta
3. 바깥: JOIN 뒤 p.name = Beta 인 행 → Charlie 한 행 → 1

헷갈리는 자리 — HAVING COUNT(*) < 2 를 "2 명 이하"로 읽어 10 · 30 까지 넣는 것(<= 가 아니다). JOIN 결과가 다섯 행인 것을 답으로 적는 것 — WHERE 가 거른 뒤의 수다. 층마다 무엇을 돌려주는지(id → 이름 → 행 수)를 적는다.

표를 sqlite 3.49 에 넣고 같은 SQL 을 실행해 결과를 확인했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 표 · 값이 실제와 다를 수 있다.

답 — 열 이름 · 성과급, 한 행 이순신 · 1000. 직원번호가 같은 행끼리 이어 붙인 뒤 성과급 500 이상만 남긴다.

원리 — FROM 직원 e, 보상 b 는 두 테이블을 전부 짝지은 뒤(3 × 3 = 9 행) WHERE e.직원번호 = b.직원번호 로 번호가 같은 짝만 남기는 옛 방식의 조인이다(JOIN … ON 과 같다). 남은 세 짝 중 b.성과급 >= 500 인 것은 101 번(1000)뿐이다. SELECT 에서 e.이름, b.성과급 두 열만 뽑으므로 결과 표는 열 둘, 행 하나다.

따라가기

1. 번호 같은 짝: 101 이순신 1000 · 102 강감찬 300 · 103 김유신 450
2. 성과급 >= 500 → 101 만
3. 결과: 이름 | 성과급 / 이순신 | 1000

헷갈리는 자리 — 답에 직원번호 열을 넣는 것(SELECT 에 없다). 450 을 "500 가까우니" 넣는 것 — 이상은 500 부터다. 표 꼴로 쓰라고 했으니 열 이름 줄을 먼저 적는다. 열 이름은 별칭이 없으니 원래 이름(이름 · 성과급)이고, e · b 같은 테이블 별칭은 결과에 안 나온다.

표를 sqlite 3.49 에 넣고 같은 SQL 을 실행해 결과를 확인했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 표 · 값이 실제와 다를 수 있다.

답 — 4. 이름 셋 × 규칙 둘 = 여섯 짝 중 LIKE 가 맞는 짝은 Smith 둘, Scott 둘이다.

원리 — CROSS JOIN 은 두 테이블의 모든 짝을 만든다(3 × 2 = 6 행). LIKE 는 무늬 맞추기로, % 는 "아무 글자 0개 이상"이다. 'S%' 는 S 로 시작, '%T%' 는 어디든 T 가 들어 있음이다. 이 문제의 정답 4 는 대소문자를 구분하지 않는 채점(Smith 의 t · Scott 의 tt 가 T 에 맞음)을 전제로 한다 — MySQL · SQL Server 의 기본이 그렇다.

따라가기

1. Smith: S% 맞음, %T% 맞음(t) → 2
2. Allen: S% 아님, %T% 아님 → 0
3. Scott: S% 맞음, %T% 맞음(tt) → 2
4. 합 4

헷갈리는 자리 — 대소문자를 구분하면(PostgreSQL · sqlite 기본) %T% 가 하나도 안 맞아 2 가 된다. 시험은 보통 구분하지 않는 쪽으로 낸다는 것을 알고 4 로 적되, 문제에 "대소문자 구분" 문구가 있으면 그것을 따른다. CROSS JOIN 의 행 수 6 을 그대로 적는 것도 오답이다.

표를 sqlite 3.49 에 넣고 같은 SQL 을 실행해 결과를 확인했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 표 · 값이 실제와 다를 수 있다.

답 — 4. WHERE 로 다섯 행이 다 걸리지만 COUNT(COL2) 는 NULL 을 세지 않아 4 다.

원리 — COUNT(*) 는 행 수를 세고, COUNT(열) 은 그 열이 NULL 이 아닌 행만 센다. NULL 은 "값 없음"이라 개수에 안 들어간다. WHERE 는 COL1 IN (2, 3) 또는 COL2 IN (3, 5) 인 행을 남기는데, NULL 은 어느 IN 에도 맞지 않지만 다른 쪽 조건으로 걸릴 수 있다. 행마다 두 조건을 따로 보고 하나라도 참이면 남긴다.

따라가기

1. (2, NULL): COL1 2 → 남음. COL2 NULL → 안 셈
2. (3, 6): COL1 3 → 남음, 셈
3. (2, 3): 남음, 셈
4. (NULL, 3): COL2 3 → 남음, 셈
5. (4, 5): COL2 5 → 남음, 셈 → COUNT(COL2) = 4

헷갈리는 자리 — COUNT(*) 로 읽어 5 를 적는 것. 괄호 안이 열 이름이면 NULL 을 뺀다. (NULL, 3) 행을 "NULL 이 있으니 제외"로 보는 것 — COL2 = 3 으로 걸린다. NULL 규칙은 두 방향(조건에서는 거짓, 개수에서는 제외) 모두 본다.

표를 sqlite 3.49 에 넣고 같은 SQL 을 실행해 결과를 확인했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 표 · 값이 실제와 다를 수 있다.

답 — ① 200 ② 3 ③ 1. COUNT(*) 는 전체 행, COUNT(DISTINCT 학과) 는 서로 다른 학과 수, WHERE 로 한 학과만 남기면 그 수는 1 이다.

원리 — COUNT(*) 는 조건을 통과한 행의 수다(200 명 → 200). DISTINCT 는 중복을 지운다 — 200 행의 학과 값 중 서로 다른 것만 세면 학과 수 3 이다. ③ 은 WHERE 로 전산과 행만 남긴 뒤 그 안의 서로 다른 학과 값을 세니, 전산과 하나뿐이라 1 이다. 행 수(몇 명)와 종류 수(몇 학과)를 나누는 것이 전부다.

따라가기

1. ① 전체 행 수 → 200
2. ② 학과의 서로 다른 값 → 3
3. ③ 전산과 행만 → 학과 값은 전산과 하나 → 1

헷갈리는 자리 — ③ 을 "전산과 학생 수"로 읽고 인원을 적는 것. DISTINCT 학과이므로 종류 수 1 이다. ② 를 200 으로 적는 것 — DISTINCT 가 있다. 세 문항이 COUNT 의 세 가지 쓰임을 정확히 나눠 묻는다. 학과 값에 NULL 인 학생이 있었다면 COUNT(DISTINCT 학과)는 NULL 을 안 세므로 ② 가 달라질 수 있다 — 문제는 그런 행이 없다고 본다.

표를 sqlite 3.49 에 넣고 같은 SQL 을 실행해 결과를 확인했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 표 · 값이 실제와 다를 수 있다.

답 — 2. 예산 평균 200 보다 큰 부서는 20(300)뿐이고, 그 부서 직원이 두 명이다.

원리 — 서브쿼리 SELECT AVG(budget) FROM dept 는 하나의 값(200)을 돌려주고, 바깥 조건은 d.budget > 200 이 된다. JOIN … ON e.dep_id = d.dept_id 는 직원 행마다 부서 정보를 붙인다 — 직원이 세 행이니 조인 결과도 세 행이고, 그중 부서 예산이 200 을 넘는 행만 센다. 부서 30 은 직원이 없어 조인에 아예 안 나온다.

따라가기

1. AVG(budget) = (100 + 300 + 200) / 3 = 200
2. 조인: 직원 10 → 예산 100, 직원 20 → 300, 직원 20 → 300
3. budget > 200 → 두 행 → 2

헷갈리는 자리 — 부서 수로 세어 1(부서 20 하나)을 적는 것. COUNT(*) 는 조인된 직원 행을 센다. 200 을 "이상"으로 보고 부서 30 까지 넣는 것 — > 는 초과이고, 30 은 직원이 없어 어차피 0 행이다.

표를 sqlite 3.49 에 넣고 같은 SQL 을 실행해 결과를 확인했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 표 · 값이 실제와 다를 수 있다.

답 — ① '이%' ② DESC. "이로 시작"은 앞이 고정되고 뒤가 자유인 무늬, 내림차순은 DESC 다.

원리 — LIKE 의 % 는 "아무 글자 0개 이상"이므로 '이%' 는 첫 글자가 이인 모든 이름이다(이순신 · 이상 · 이정재). 문자열이라 작은따옴표로 감싼다. ORDER BY 이름 은 기본이 오름차순(ASC)이고 내림차순은 뒤에 DESC 를 붙인다. 이름이 한글이면 가나다 역순이다.

따라가기

1. LIKE '이%' → 이순신, 이상, 이정재
2. ORDER BY 이름 DESC → 이정재, 이순신, 이상

헷갈리는 자리 — '%이%' 로 적는 것(어디든 이가 들어가면 임꺽정 · 김영희는 안 걸리지만 뜻이 다르다). 따옴표를 빼는 것. ② 에 DESCENDING 이나 "내림차순"을 적는 것 — 예약어는 DESC 다. 한 글자 자리에는 _ 를 쓴다는 것도 같은 묶음이다. 예를 들어 '이_' 는 두 글자 이름 이상만 걸리고, '%신' 은 신으로 끝나는 이순신만 걸린다 — %와 _ 의 자리로 무늬를 읽는다.

표를 sqlite 3.49 에 넣고 같은 SQL 을 실행해 결과를 확인했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 표 · 값이 실제와 다를 수 있다.

답 — 3. A 의 행마다 "자기보다 x 가 작은 행들의 id 에 해당하는 B.y 평균"을 구해 견주면, x 가 20 · 30 · 40 인 세 행이 남는다.

원리 — 안쪽 SELECT 가 바깥 행의 값(A.x)을 쓰므로 바깥 행마다 서브쿼리를 다시 계산해야 한다(상관 서브쿼리). 절차는 셋이다: 가장 안쪽에서 "지금 행보다 x 가 작은 A 행들의 id" 목록을 만들고, 가운데에서 B 중 그 id 인 행들의 y 평균을 내고, 바깥에서 지금 행의 x 가 그 평균보다 큰지 본다. 목록이 비면 평균은 NULL 이고 NULL 과의 비교는 참이 아니라 그 행은 빠진다.

따라가기

1. x = 10: 더 작은 x 없음 → 목록 비어 AVG NULL → 제외
2. x = 20: 목록 {1} → B.y 5, 15 → 평균 10 → 20 > 10 ✓
3. x = 30: 목록 {1, 2} → 5, 15, 20 → 평균 13.3 → ✓
4. x = 40: 목록 {1, 2, 3} → 5, 15, 20, 35 → 평균 18.75 → ✓ → 3

헷갈리는 자리 — 첫 행을 "비교할 것이 없으니 참"으로 보고 4 를 적는 것. NULL 비교는 거짓 취급이다. B 의 id 5 행(50)은 A 에 없는 id 라 한 번도 안 쓰인다는 것과, 상관 서브쿼리는 행마다 다시 센다는 것이 이 문제의 두 축이다.

표를 sqlite 3.49 에 넣고 같은 SQL 을 실행해 결과를 확인했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 표 · 값이 실제와 다를 수 있다.

답 — 2. RIGHT OUTER JOIN 은 B 의 행을 전부 남기므로 짝이 없는 B 의 id 3 · 4 가 A 쪽 NULL 로 나오고, 그 두 행만 A.id IS NULL 에 걸린다.

원리 — RIGHT OUTER JOIN 은 오른쪽 테이블(B)의 모든 행을 결과에 남기고, 왼쪽(A)에 짝이 있으면 붙이고 없으면 A 쪽 열을 NULL 로 채운다. 그래서 "B 에는 있는데 A 에는 없는 것"을 찾으려면 WHERE A.id IS NULL 을 건다 — 외부 조인의 대표 용법이다. A 의 id 1 이 두 행이라 B 의 id 1 은 두 번 나오지만 A.id 가 있으니 세지 않는다. NULL 은 = NULL 로 못 찾고 IS NULL 로만 찾는다.

따라가기

1. B id 1 ↔ A 두 행 → 2행(A.id 1)
2. B id 2 ↔ A 한 행 → 1행(A.id 2)
3. B id 3 · 4 ↔ 짝 없음 → A.id NULL → 2행
4. WHERE A.id IS NULL → 2

헷갈리는 자리 — 조인 결과 전체 5 행을 적는 것. INNER JOIN 으로 읽어 0 을 적는 것 — 내부 조인은 짝 없는 행이 아예 없어 IS NULL 이 하나도 안 걸린다. LEFT 였다면 A 쪽 전부가 남아 답이 0 이다 — 방향이 곧 답이다.

표를 sqlite 3.49 에 넣고 같은 SQL 을 실행해 결과를 확인했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 표 · 값이 실제와 다를 수 있다.

답 — 열 이름 · 평균, 한 행 박C · 95. 이름별 평균이 85 를 넘는 사람은 박C 뿐이다.

원리 — GROUP BY 이름 은 같은 이름의 행을 묶고, AVG(점수) 는 묶음마다 평균을 낸다. HAVING AVG(점수) > 85 는 묶은 뒤 평균에 거는 조건이라 85 는 안 들어간다(초과). 김A 는 (90 + 80) / 2 = 85, 이B 는 (70 + 100) / 2 = 85 라 둘 다 탈락이고 박C 는 95 하나뿐이라 평균 95 다.

따라가기

1. 김A → 85(탈락), 이B → 85(탈락), 박C → 95
2. HAVING > 85 → 박C 만
3. 결과 박C | 95 (열 이름은 이름 · 평균)

헷갈리는 자리 — > 를 >= 로 읽어 세 사람을 다 남기는 것. "초과"와 "이상"은 다르다. 평균 열 이름을 AVG(점수)로 적는 것 — AS 평균 이 있으니 평균이다.

이전 자료의 예상 문제다. sqlite 3.49 에서 실행해 정답을 확인했다.

답 — ① 2 ② 3. INNER JOIN 은 짝이 있는 행만, LEFT JOIN 은 왼쪽(사원) 행 전부를 남긴다.

원리 — 조인은 두 테이블의 행을 조건(부서코드가 같음)으로 짝짓는다. INNER JOIN 은 짝이 맞는 행만 결과에 넣는다 — 박의 부서코드가 NULL 이라 어느 부서와도 못 맞아 빠진다. LEFT JOIN 은 왼쪽 테이블의 모든 행을 남기고 짝이 없으면 오른쪽 열을 NULL 로 채운다 — 박도 남는다. NULL 은 어떤 값과도 같지 않으므로 NULL 끼리도 짝이 안 된다.

따라가기

1. 김(A) ↔ 영업, 이(B) ↔ 개발, 박(NULL) ↔ 없음
2. INNER → 김 · 이 → 2
3. LEFT → 김 · 이 · 박(부서 NULL) → 3

헷갈리는 자리 — 부서 테이블에 없는 코드가 아니라 NULL 이라도 결과는 같다 — 짝이 없으면 INNER 에서 빠진다. RIGHT JOIN 이었다면 부서 쪽 전부가 남아 2 다.

이전 자료의 예상 문제다. sqlite 3.49 에서 실행해 정답을 확인했다.

답 — 0. 괄호로 OR 를 먼저 묶었으므로 "A 이면서 (80 이상이거나 C)" 인데, A 인 행은 70 · 50 이라 둘 다 탈락이다.

원리 — 2024년 1회 18번과 같은 표에 괄호만 넣은 변형이다. 괄호가 있으면 안의 OR 가 먼저 계산되고, 그다음 바깥 AND 가 걸린다. KIND 가 A 인 행에서만 두 번째 조건을 보는 셈인데, A 의 점수는 80 미만이고 A 이면서 동시에 C 일 수는 없으니 남는 행이 없다.

따라가기

1. KIND = 'A' 인 행: 1번(70), 3번(50)
2. 괄호 안 (SCORE >= 80 OR KIND = 'C') → 둘 다 거짓
3. COUNT(*) → 0

이 노트에서 만든 변형 문제다. 표를 sqlite 3.49 에 넣고 실행해 정답을 확인했다.

답 — 5, 4, 4.25. 행 수는 5, COL1 이 NULL 이 아닌 행은 4, COL2 평균은 NULL 을 뺀 네 값의 평균이다.

원리 — COUNT(*) 는 NULL 과 상관없이 행을 센다. COUNT(COL1) 은 COL1 이 NULL 인 행을 빼고 센다. AVG(COL2) 도 NULL 을 빼고 "값이 있는 것들의 합 ÷ 값이 있는 개수"다 — NULL 을 0 으로 치지 않는다. 집계 함수는 * 를 빼면 전부 NULL 을 무시한다는 한 줄 규칙이다.

따라가기

1. COUNT(*) = 5
2. COL1: 2, 3, 2, NULL, 4 → NULL 제외 4
3. COL2: NULL, 6, 3, 3, 5 → (6 + 3 + 3 + 5) / 4 = 17 / 4 = 4.25

이 노트에서 만든 변형 문제다. 표를 sqlite 3.49 에 넣고 실행해 정답을 확인했다.

답 — 3. LEFT OUTER JOIN 은 왼쪽 A 의 행을 전부 남기므로 A 의 행 수 3 이 그대로다.

원리 — 2026년 2회 18번(RIGHT)을 LEFT 로 바꾼 변형이다. LEFT 는 왼쪽 테이블이 기준이라 A 의 세 행이 모두 결과에 남고, 각 행의 id 가 B 에 있으면 그 값을 붙인다. A 의 id 1 · 1 · 2 는 전부 B 에 있어 NULL 도 안 생기고, B 의 3 · 4 는 A 에 없어 아예 안 나온다. 왼쪽 행 하나가 오른쪽 여러 행과 맞으면 그만큼 늘지만 여기서는 B 의 id 가 하나씩이라 3 이다.

따라가기

1. A(1, 10) ↔ B(1, 100), A(1, 20) ↔ B(1, 100), A(2, 30) ↔ B(2, 200)
2. 결과 3 행 → 3

이 노트에서 만든 변형 문제다. 표를 sqlite 3.49 에 넣고 실행해 정답을 확인했다.

답 — 학년 · 인원 두 열, (3, 2) 와 (4, 1) 두 행. 이름에 이가 든 사람만 남겨 학년별로 세고 학년순으로 늘어놓는다.

원리 — 절이 실행되는 순서는 FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY 다. WHERE LIKE '%이%' 로 먼저 행을 거르고(이순신 · 이상 · 이정재), 학년별로 묶어 COUNT 하고, HAVING 은 1 이상이라 아무것도 안 거르며, 마지막에 학년 오름차순으로 정렬한다. 김영희의 희는 이가 아니다.

따라가기

1. WHERE → 이순신(3), 이상(4), 이정재(3)
2. GROUP BY 학년 → 3학년 2명, 4학년 1명
3. ORDER BY 학년 → 3 | 2, 4 | 1

이 노트에서 만든 변형 문제다. 표를 sqlite 3.49 에 넣고 실행해 정답을 확인했다.

답 — 0. 서브쿼리에 맞는 행이 없어 AVG 가 NULL 이 되고, NULL 과 비교한 조건은 참이 될 수 없다.

원리 — AVG 는 값이 하나도 없으면 0 이 아니라 NULL 을 돌려준다. x > NULL 은 참도 거짓도 아닌 "모름"이라 WHERE 는 그 행을 버린다. 2026년 2회 11번의 첫 행(비교 대상이 없어 빠짐)이 같은 규칙이다. COUNT 만 예외로 값이 없을 때 0 을 돌려준다.

따라가기

1. x > 100 인 행 없음 → AVG(x) = NULL
2. 모든 행에서 x > NULL → 모름 → 버림
3. COUNT(*) → 0

이 노트에서 만든 변형 문제다. 표를 sqlite 3.49 에 넣고 실행해 정답을 확인했다.