F-2: MySQL 함수·조인·계층형 변환 — 인스타 쿼리를 통째로 옮기기

안녕하세요, 홍순구 튜터입니다. 지난 시간엔 인스타그램 스키마를 Oracle 에서 MySQL 8.4 로 옮기면서 자료형(VARCHAR2→VARCHAR·DATE→DATETIME), 자동 채번(시퀀스→AUTO_INCREMENT), 피드 페이지네이션(ROWNUM→LIMIT), NULL 메우기(NVL→IFNULL)까지 방언의 기초를 한 바퀴 돌았죠. 그러면서 마지막에 "함수와 복잡한 쿼리는 더 많이 갈린다" 고 예고했어요. 오늘이 바로 그 본론이에요.

오늘은 날짜를 예쁘게 출력하던 TO_CHAR 가 MySQL 의 DATE_FORMAT 으로, 대댓글 트리를 따라가던 CONNECT BY(D-3)가 WITH RECURSIVE 로 바뀌는 모습을 직접 옮겨 봐요. 함수·조인·계층형까지 통째로요. 그리고 시작은 좀 의외의 함정으로 열게요. 바로 "빈칸이 빈칸이 아닌" 이야기예요. Oracle 과 MySQL 이 빈 문자열을 서로 다르게 보거든요. 이 차이를 모르면 멀쩡한 쿼리가 회사를 옮기는 순간 슬그머니 틀려요.

 오늘의 여정
   ① 빈칸이 빈칸이 아니다 — 빈 문자열과 NULL
   ② 날짜를 글자로 — TO_CHAR vs DATE_FORMAT
   ③ 문자열 잇기와 조건 분기 — || 와 DECODE
   ④ 한쪽이 비어도 다 보여주기 — (+) vs ANSI JOIN
   ⑤ 대댓글 트리 — CONNECT BY vs WITH RECURSIVE
   ⑥ 태그를 한 줄로 — LISTAGG vs GROUP_CONCAT
   ⑦ 통째로 옮기고 다음 과목으로 — 변환 한 장 정리

💡 오늘 수업의 핵심 — "Oracle 함수·외부조인·계층형 쿼리를 MySQL 8.4 로 옮기며, 빈 문자열 함정·DATE_FORMAT·CONCAT·ANSI JOIN·WITH RECURSIVE·GROUP_CONCAT 이라는 방언 차이를 정리한다"

🎯 학습 목표

• 빈 문자열을 Oracle 은 NULL 로, MySQL 은 빈 문자열로 본다는 차이를 안다. (SQLD 방언 함정 ★빈출)
• TO_CHAR↔DATE_FORMAT, ||↔CONCAT, DECODE↔CASE, (+)↔ANSI JOIN 변환을 안다.
• CONNECT BY↔WITH RECURSIVE, LISTAGG↔GROUP_CONCAT 으로 계층형·집계 쿼리를 옮긴다.

Step 1: "빈칸이 빈칸이 아니다 — 빈 문자열과 NULL"

지난 시간 NULL 을 메우는 NVL·IFNULL 을 다뤘죠. 오늘은 그 NULL 과 빈 문자열('')의 관계부터 짚어요. 둘이 같아 보이지만, 두 데이터베이스가 이걸 정반대로 봐요. 여기서 사고가 자주 나요.

먼저 용어를 맞출게요. 빈 문자열(empty string) 은 따옴표 안에 아무것도 없는 '' 예요. 길이가 0 인 글자죠. 반면 NULL 은 "값이 아예 없음" 이에요. C-3 에서 NULL 은 빈칸도 0 도 아닌 "미지의 상태" 라고 했죠. 그런데 Oracle 은 이 둘을 같다고 봐요. Oracle 에 빈 문자열을 넣으면 그게 NULL 로 저장돼요. MySQL 은 다르다고 봐요. 빈 문자열은 길이 0 짜리 멀쩡한 값이고, NULL 이 아니에요.

우리 회원 중 자기소개(bio)가 빈 회원이 있죠. 여기에 시험 삼아 자기소개를 ''(빈 문자열)로 넣은 회원을 하나 추가했다가, "자기소개가 NULL 인 회원" 을 세 보면 두 데이터베이스의 답이 갈려요.

-- sql/migration/oracle_to_mysql/06_queries_f2_mysql.sql
-- MySQL: '' 는 NULL 이 아니다
SELECT ('' IS NULL) AS empty_is_null,   -- 0 (거짓)
       ('' = '')    AS empty_eq_empty,  -- 1 (참)
       LENGTH('')   AS len_empty;       -- 0

MySQL 에선 '' IS NULL 이 거짓(0)이에요. 빈 문자열은 길이 0 인 값일 뿐 NULL 이 아니라는 뜻이죠. 그래서 빈 자기소개를 넣은 회원은 bio IS NULL 로 셀 때 빠져요. 원래 비어 있던 4명만 세어져요.

그런데 Oracle 에서 똑같이 빈 문자열을 넣고 세면 5명 이 나와요. Oracle 은 빈 문자열을 NULL 로 저장하니, 방금 넣은 회원까지 "소개가 NULL" 로 함께 세어지거든요.

 같은 INSERT, 다른 해석
   Oracle :  bio 에 ''  →  NULL 로 저장    →  IS NULL 이 셈    (소개 없는 회원 5명)
   MySQL  :  bio 에 ''  →  빈 문자열 그대로  →  IS NULL 이 안 셈  (소개 없는 회원 4명)

같은 데이터, 같은 쿼리인데 답이 4 와 5 로 갈렸어요. 이게 Oracle 로 짠 쿼리를 MySQL 로 옮길 때(혹은 그 반대) 가장 조용하게 사람을 잡는 함정이에요. 에러도 안 나고 결과만 슬쩍 달라지니까요.

⚠️ Oracle 은 빈 문자열('')을 NULL 로 저장하지만, MySQL 은 빈 문자열을 길이 0 의 값으로 본다(NULL 아님). "빈 값을 어떻게 셀까" 를 IS NULL 로만 짜면 두 방언에서 결과가 갈린다. ★빈출

💡 한 줄 정리 — Oracle 에서 '' = NULL, MySQL 에서 '' ≠ NULL. 빈 문자열까지 비었다고 보려면 MySQL 에선 bio IS NULL OR bio = '' 처럼 둘 다 확인해야 한다.

Step 2: "날짜를 글자로 — TO_CHAR vs DATE_FORMAT"

C-2 에서 날짜를 원하는 모양의 글자로 바꾸는 TO_CHAR 를 배웠죠. TO_CHAR(created_at, 'YYYY-MM-DD') 처럼요. MySQL 도 똑같은 일을 하는데, 함수 이름이 DATE_FORMAT 이고 포맷을 적는 방식이 달라요. Oracle 은 YYYY·MM 같은 글자로, MySQL 은 %Y·%m 처럼 퍼센트 기호로 적어요.

게시물의 작성 시각을 여러 모양으로 출력해 볼게요.

-- sql/migration/oracle_to_mysql/06_queries_f2_mysql.sql
-- Before(Oracle): TO_CHAR(created_at, 'YYYY-MM-DD HH24:MI:SS')
SELECT post_id,
       DATE_FORMAT(created_at, '%Y-%m-%d')          AS ymd,      -- 2026-06-01
       DATE_FORMAT(created_at, '%Y-%m-%d %H:%i:%s')  AS full_ts,  -- 2026-06-01 00:00:00
       DATE_FORMAT(created_at, '%Y년 %m월 %d일')     AS kor,
       DATE_FORMAT(created_at, '%Y-%m')             AS ym
FROM post WHERE post_id IN (1, 12, 50) ORDER BY post_id;

첫 게시물의 작성일이 2026-06-01, 시각까지 붙이면 2026-06-01 00:00:00, 한글로 꾸미면 2026년 06월 01일 로 나와요. 지난 시간에 DATE→DATETIME 으로 옮긴 덕에 시각(00:00:00)까지 살아 있죠.

포맷 글자를 한 표로 맞춰 볼게요. 옮길 때 이 표만 있으면 헷갈리지 않아요.

여기서 제일 잘 틀리는 게 분 이에요. Oracle 은 분이 MI 인데, MySQL 은 분이 %i 예요. 그런데 MySQL 의 %m 은 분이 아니라 월 이거든요. 손이 가는 대로 분을 %m 으로 적으면, 분 자리에 엉뚱하게 월이 찍혀요.

-- ⚠️ %i(분) vs %m(월) : 같은 시각(13시 45분 30초)을 두 포맷으로
SELECT DATE_FORMAT('2026-06-01 13:45:30', '%H:%i:%s') AS correct_i,  -- 13:45:30 (분)
       DATE_FORMAT('2026-06-01 13:45:30', '%H:%m:%s') AS wrong_m;    -- 13:06:30 (%m=월!)

%i 로 적으면 13:45:30 으로 분(45)이 제대로 나오는데, %m 으로 적으면 13:06:30 으로 분 대신 6월의 06 이 찍혀요. 시각이 통째로 틀어지는 거죠. "MySQL 에서 분은 %i, %m 은 월" 이라고 단단히 기억해 두세요.

반대로 글자를 날짜로 되돌리는 것도 짝이 있어요. Oracle 의 TO_DATE('2026-06-01', 'YYYY-MM-DD') 는 MySQL 에선 STR_TO_DATE('2026-06-01', '%Y-%m-%d') 예요. 출력은 DATE_FORMAT, 입력은 STR_TO_DATE 로 짝을 지어 외우면 편해요.

⚠️ MySQL DATE_FORMAT 에서 분은 %i 다. %m 은 월이라, 분을 %m 으로 적으면 분 대신 월이 찍힌다. Oracle 의 MI(분)·MM(월) 구분과 같은 함정이 기호만 바뀌어 그대로 있다. ★빈출

💡 한 줄 정리 — 날짜를 글자로는 Oracle TO_CHAR, MySQL DATE_FORMAT(%Y-%m-%d). 글자를 날짜로는 TO_DATE↔STR_TO_DATE. 분은 %i(%m 은 월).

Step 3: "문자열 잇기와 조건 분기 — || 와 DECODE"

함수 두 개를 더 옮겨 볼게요. 둘 다 우리가 이미 Oracle 로 써 봤던 거예요. 문자열을 잇는 || 와, 조건에 따라 값을 고르는 DECODE 죠. 그런데 이 둘은 MySQL 에서 특히 조심해야 해요. 하나는 있는데 뜻이 다르고, 하나는 아예 없거든요.

먼저 문자열 잇기예요. Oracle 에선 nickname || '님' 처럼 || 로 글자를 이어 붙였죠. MySQL 에도 || 기호가 있긴 한데, 여기선 글자를 잇는 게 아니라 논리 OR(또는)을 뜻해요. 그래서 MySQL 에서 nickname || '님' 을 적으면, 글자가 이어지는 대신 두 값을 참/거짓으로 따져서 엉뚱한 숫자가 나와요.

-- sql/migration/oracle_to_mysql/06_queries_f2_mysql.sql
-- Before(Oracle): nickname || '님'  →  '김재훈님' (연결)
SELECT nickname,
       (nickname || '님')     AS pipe_result,    -- 0  (MySQL 에선 || 가 OR!)
       CONCAT(nickname, '님') AS concat_result    -- 김재훈님
FROM member WHERE member_id IN (1, 2) ORDER BY member_id;

nickname || '님' 의 결과가 김재훈님 이 아니라 0 으로 나왔죠. MySQL 이 || 를 OR 로 해석해서, 글자 '김재훈' 과 '님' 을 각각 거짓으로 보고 "거짓 또는 거짓 = 0" 을 돌려준 거예요. MySQL 에서 글자를 이으려면 반드시 CONCAT 을 써야 해요. CONCAT(nickname, '님') 이라야 김재훈님 이 나와요. Oracle 의 || 가 MySQL 에선 CONCAT 이라고 짝지어 두세요.

다음은 조건 분기예요. C-3 에서 Oracle 의 DECODE 를 배웠죠. DECODE(MOD(member_id,2), 0, '짝수회원', '홀수회원') 처럼 값을 짝지어 고르는 함수였어요. 그런데 DECODE 는 Oracle 전용 이라 MySQL 엔 아예 없어요. 대신 우리가 함께 배운 표준 CASE 를 쓰면 돼요. CASE 는 Oracle·MySQL 어디서나 통하는 표준어니까요. MySQL 만의 짧은 IF 함수도 있고요.

-- Before(Oracle): DECODE(MOD(member_id,2), 0, '짝수회원', '홀수회원')
SELECT member_id,
       CASE MOD(member_id, 2) WHEN 0 THEN '짝수회원' ELSE '홀수회원' END AS by_case,
       IF(MOD(member_id, 2) = 0, '짝수회원', '홀수회원')                  AS by_if
FROM member ORDER BY member_id;   -- 짝수 6명 · 홀수 6명

CASE 와 IF 둘 다 같은 결과를 내요. 짝수 회원 6명, 홀수 회원 6명으로 갈리죠. CASE 는 표준이라 어디서나 통하고, IF 는 MySQL 사투리라 짧게 쓰기 좋아요. 옮길 일을 생각하면 CASE 가 안전한 기본값이에요.

⚠️ MySQL 의 || 는 문자열 연결이 아니라 논리 OR 다. 글자를 이으려면 CONCAT 을 써야 한다. 그리고 DECODE 는 Oracle 전용이라 MySQL 엔 없으니 표준 CASE(또는 IF)로 옮긴다. ★빈출

💡 한 줄 정리 — 문자열 잇기는 Oracle || → MySQL CONCAT(MySQL 의 || 는 OR). 조건 분기는 Oracle DECODE → 표준 CASE(또는 MySQL IF).

Step 4: "한쪽이 비어도 다 보여주기 — (+) vs ANSI JOIN"

C-5 에서 외부 조인(OUTER JOIN)을 배웠죠. 한쪽 테이블에 짝이 없어도 그 행을 살려 두는 조인이요. 그때 표준 ANSI 문법(LEFT JOIN ... ON)과 Oracle 만의 옛 문법인 (+) 기호를 같이 봤어요. 이 둘을 MySQL 로 옮기면 어떻게 될까요?

좋은 소식이 있어요. 우리가 평소에 쓰던 ANSI JOIN(LEFT JOIN·INNER JOIN)은 MySQL 에서도 그대로 통해요. 표준어라서요. 문제는 Oracle 만의 (+) 예요. 이건 MySQL 에 아예 없어요. 그래서 (+) 로 짠 외부 조인은 MySQL 로 옮길 때 반드시 ANSI LEFT JOIN 으로 고쳐 써야 해요.

글이 하나도 없는 회원까지 포함해서, 회원별 게시물을 이어 볼게요. C-5 에서 본 그 쿼리예요.

-- sql/migration/oracle_to_mysql/06_queries_f2_mysql.sql
-- Before(Oracle): FROM member m, post p WHERE m.member_id = p.member_id(+)
SELECT COUNT(*) AS left_join_rows                       -- 53
FROM member m LEFT JOIN post p ON m.member_id = p.member_id;

결과는 53행 이에요. 게시물 50개에, 글이 하나도 없는 회원 3명(7·8·10)이 짝 없이도 살아남아서 더해진 거죠. Oracle 에서 (+) 로 짜도 똑같이 53행이 나와요. 두 문법이 같은 일을 한 거예요. 글 없는 회원이 누군지도 그대로 확인돼요.

-- 글이 하나도 없는 회원도 LEFT JOIN 으로 살아남는다 → 윤태양·한나래·이민수
SELECT m.member_id, m.nickname, COUNT(p.post_id) AS post_cnt
FROM member m LEFT JOIN post p ON m.member_id = p.member_id
GROUP BY m.member_id, m.nickname
HAVING COUNT(p.post_id) = 0
ORDER BY m.member_id;

게시물 0개 회원 7(윤태양)·8(한나래)·10(이민수)이 그대로 잡혀요. C-5 에서 봤던 그 경계 회원들이죠.

 Oracle (+)                          ANSI LEFT JOIN
   FROM m, p                           FROM m LEFT JOIN p
   WHERE m.id = p.id(+)                  ON m.id = p.id
   (+) 붙은 p 쪽은 '없어도 됨'          LEFT 쪽(m)을 다 살림
   MySQL 엔 (+) 가 없음                 두 방언 다 통하는 표준

한 가지 더 짚을 게 있어요. C-5 에서 양쪽을 다 살리는 FULL OUTER JOIN 도 봤죠. 그런데 MySQL 은 FULL OUTER JOIN 도 없어요. MySQL 에서 양쪽을 다 살리려면 LEFT JOIN 결과와 RIGHT JOIN 결과를 UNION 으로 합쳐서 흉내 내요. Oracle 의 (+) 가 한쪽 방향만 되던 것처럼, MySQL 도 외부 조인엔 나름의 한계가 있는 셈이에요.

⚠️ Oracle 의 (+) 외부 조인 문법은 MySQL 에 없다. 반드시 ANSI LEFT/RIGHT JOIN ... ON 으로 옮긴다. MySQL 은 FULL OUTER JOIN 도 없어서 LEFT ∪ RIGHT(UNION)로 흉내 낸다.

💡 한 줄 정리 — ANSI JOIN(LEFT/INNER ... ON)은 두 방언 다 통한다. Oracle 전용 (+) 는 MySQL 에 없으니 ANSI LEFT JOIN 으로 옮긴다. 그래서 처음부터 표준 ANSI 로 짜 두면 옮길 게 없다.

Step 5: "대댓글 트리 — CONNECT BY vs WITH RECURSIVE"

오늘의 가장 큰 산이에요. D-3 에서 대댓글 트리를 따라 내려가는 계층형 질의를 배웠죠. Oracle 의 START WITH·CONNECT BY 로요. 그런데 이 CONNECT BY 는 Oracle 만의 강력한 사투리예요. MySQL 엔 없어요. MySQL 은 같은 일을 표준 문법인 재귀 CTE(WITH RECURSIVE)로 해요.

잠깐 개념부터요. CTE(Common Table Expression)는 D-2 에서 본 WITH 절, 즉 "쿼리 안에서 잠깐 쓰는 이름 붙인 임시 결과" 였죠. 재귀 CTE 는 그 임시 결과가 자기 자신을 다시 불러서 한 단계씩 더 내려가는 거예요. 루트 댓글에서 시작해서, 그 자식을 찾고, 또 그 자식의 자식을 찾고... 트리 끝까지 반복하는 거죠. CONNECT BY 가 한 줄로 하던 일을, 재귀 CTE 는 "시작점 + 한 단계 내려가는 규칙" 두 부분으로 나눠서 적어요.

게시물 1 의 대댓글 트리(깊이 4)를 MySQL 로 펼쳐 볼게요.

-- sql/migration/oracle_to_mysql/06_queries_f2_mysql.sql
-- Before(Oracle): START WITH parent_comment_id IS NULL
--                 CONNECT BY PRIOR comment_id = parent_comment_id
WITH RECURSIVE comment_tree AS (
    SELECT comment_id, parent_comment_id, content, 1 AS lv,
           CAST(LPAD(comment_id, 5, '0') AS CHAR(200)) AS path
    FROM   post_comment
    WHERE  post_id = 1 AND parent_comment_id IS NULL          -- 시작점(루트)
    UNION ALL
    SELECT c.comment_id, c.parent_comment_id, c.content, ct.lv + 1,
           CONCAT(ct.path, '/', LPAD(c.comment_id, 5, '0'))
    FROM   post_comment c
    JOIN   comment_tree ct ON c.parent_comment_id = ct.comment_id  -- 부모-자식 연결(재귀)
    WHERE  c.post_id = 1
)
SELECT lv, CONCAT(REPEAT('    ', lv - 1), content) AS tree
FROM   comment_tree
ORDER  BY path;

UNION ALL 의 위가 시작점(루트 댓글, parent_comment_id IS NULL)이고, 아래가 한 단계 내려가는 규칙(자기 자신인 comment_tree 를 다시 조인)이에요. 이 구조가 START WITH(시작점)와 CONNECT BY(연결 규칙)에 정확히 대응해요. 결과는 게시물 1 의 댓글 7건, 가장 깊은 곳이 4단계예요.

 게시물 1 댓글 트리 (깊이 4)
   [1] 첫 게시물 축하해요!              (루트)
    └ [2] 감사합니다 민지님
        └ [3] 별말씀을요 ㅎㅎ
            └ [4] 앞으로 자주 올게요!    ← 깊이 4 · 잎
    └ [2] 민지님 말 맞아요 ㅎㅎ
   [1] 시작이 좋네요 ㅎㅎ
   [1] 잘 보고 가요

옮기면서 손볼 데가 세 군데 있어요. 첫째, WITH 뒤에 RECURSIVE 를 꼭 붙여요. Oracle 은 WITH 만 써도 재귀인 걸 알아서 추론하지만, MySQL 은 WITH RECURSIVE 라고 분명히 적어 줘야 해요. 둘째, Oracle 의 LEVEL 의사컬럼(깊이를 알려주던 자동 컬럼)이 MySQL 엔 없어요. 그래서 lv 라는 컬럼을 직접 두고 한 단계 내려갈 때마다 +1 로 키워요. 셋째, 깊이 우선 순서를 맞추는 방법이 달라요.

세 번째를 조금 더 볼게요. D-3 에서 트리 순서를 보존하려고 ORDER SIBLINGS BY 를 썼죠. MySQL 엔 그게 없어요. 대신 위 쿼리처럼 부모의 경로 뒤에 자기 번호를 이어 붙인 path 문자열 을 만들고, 마지막에 ORDER BY path 로 정렬해요. 00001 → 00001/00003 → 00001/00003/00017 처럼 경로가 쌓이니, 이 글자 순서로 정렬하면 부모 바로 밑에 자식이 오는 깊이 우선 순서가 자연스럽게 맞아요. 번호를 LPAD 로 0 채워 길이를 맞춘 건, 글자 정렬이 숫자 정렬과 어긋나지 않게 하려는 장치예요.

⚠️ MySQL 엔 CONNECT BY 가 없다. WITH RECURSIVE(키워드 RECURSIVE 필수)로 옮긴다. LEVEL 은 직접 키운 lv 컬럼으로, ORDER SIBLINGS BY(깊이 우선)는 경로 문자열을 만들어 ORDER BY path 로 대신한다. ★빈출

💡 한 줄 정리 — 계층형은 Oracle CONNECT BY → 표준 WITH RECURSIVE. UNION ALL 위가 시작점, 아래가 재귀 규칙. 깊이는 lv +1, 깊이 우선 순서는 path 정렬로 맞춘다.

Step 6: "태그를 한 줄로 — LISTAGG vs GROUP_CONCAT"

마지막 함수예요. D-6 에서 한 게시물의 해시태그 여러 개를 '여행, 제주, 바다' 처럼 한 줄 문자열로 모으는 LISTAGG 를 배웠죠. 여러 행을 한 칸으로 합치는 집계였어요. MySQL 은 같은 일을 GROUP_CONCAT 으로 해요. 이름은 다르지만 하는 일은 같아요.

게시물별 해시태그를 한 줄로 모아 볼게요.

-- sql/migration/oracle_to_mysql/06_queries_f2_mysql.sql
-- Before(Oracle): LISTAGG(h.name, ', ') WITHIN GROUP (ORDER BY h.hashtag_id)
SELECT p.post_id,
       GROUP_CONCAT(h.name ORDER BY h.hashtag_id SEPARATOR ', ') AS tags
FROM post p
JOIN post_hashtag ph ON p.post_id = ph.post_id
JOIN hashtag h ON ph.hashtag_id = h.hashtag_id
WHERE p.post_id IN (1, 12, 40)
GROUP BY p.post_id
ORDER BY p.post_id;   -- post 12 → '여행, 제주, 바다'

게시물 12 의 태그가 여행, 제주, 바다 로 한 줄에 모였어요. D-6 의 LISTAGG 와 똑같은 결과죠. 두 함수의 문법을 짝지어 보면 이래요. LISTAGG 의 WITHIN GROUP (ORDER BY ...) 가 GROUP_CONCAT 에선 함수 괄호 안 의 ORDER BY ... 로 들어가요. 그리고 구분자는 LISTAGG 가 두 번째 인자로 받지만, GROUP_CONCAT 은 끝에 SEPARATOR ', ' 로 적어요. 이걸 빼면 기본 구분자가 공백 없는 쉼표(,)라 여행,제주,바다 처럼 붙어 나와요.

NULL 도 D-6 과 똑같이 동작해요. 태그가 하나도 없는 게시물을 LEFT JOIN 으로 끌어오면, 그 게시물의 GROUP_CONCAT 결과는 NULL 이에요. 그래서 C-3 에서 배운 COALESCE 로 메워 줘요.

-- 태그 없는 게시물은 GROUP_CONCAT 도 NULL → COALESCE 로 '태그 없음'
SELECT p.post_id,
       COALESCE(GROUP_CONCAT(h.name ORDER BY h.name SEPARATOR ', '), '태그 없음') AS tags
FROM post p
LEFT JOIN post_hashtag ph ON p.post_id = ph.post_id
LEFT JOIN hashtag h ON ph.hashtag_id = h.hashtag_id
GROUP BY p.post_id
ORDER BY p.post_id;

태그가 없는 게시물 22개가 태그 없음 으로 채워져요. LISTAGG 가 개별 NULL 은 건너뛰고 그룹 전체가 비었을 때만 NULL 을 내던 그 동작이, GROUP_CONCAT 에서도 똑같아요.

GROUP_CONCAT 엔 한 가지 조심할 함정이 있어요. 모은 문자열이 기본 1024 바이트 를 넘으면 거기서 잘려요. 태그 몇 개야 괜찮지만, 한 그룹에 수백 개를 모으면 뒤가 소리 없이 잘려 나가요. 한글은 한 글자가 3바이트라 더 빨리 차고요. 길게 모아야 하면 SET SESSION group_concat_max_len = 100000; 처럼 상한을 미리 늘려요.

SELECT @@group_concat_max_len AS gc_max_len;   -- 1024 (기본값)

⚠️ GROUP_CONCAT 은 기본 1024 바이트에서 결과가 잘린다(에러 없이 조용히). 길게 모을 땐 group_concat_max_len 을 늘려야 한다. Oracle LISTAGG 도 한도(보통 4000 바이트)를 넘으면 에러가 나니, 둘 다 길이 한도가 있다는 걸 기억한다.

💡 한 줄 정리 — 여러 행을 한 줄 문자열로는 Oracle LISTAGG → MySQL GROUP_CONCAT. WITHIN GROUP (ORDER BY) 는 괄호 안 ORDER BY, 구분자는 SEPARATOR. 기본 1024 바이트 한도에 주의한다.

Step 7: "통째로 옮기고 다음 과목으로 — 변환 한 장 정리"

오늘과 지난 시간에 옮긴 방언을 한 장으로 모아 볼게요. Oracle 로 짠 인스타 쿼리를 MySQL 로 옮길 때 손보는 데가 결국 이 표 하나로 정리돼요. 시험 직전이든 실무에서 변환할 때든, 이 표만 떠올리면 길을 잃지 않아요.

윗줄 다섯 개는 지난 시간(F-1)에, 아랫줄 일곱 개는 오늘 옮긴 거예요. 이 표만큼은 익혀 두면, 어떤 인스타 쿼리가 와도 한 줄씩 짚어 가며 옮길 수 있어요. 핵심은 "표준어(CONCAT·COALESCE·CASE·ANSI JOIN·WITH RECURSIVE)로 짜 두면 옮길 게 적다" 는 거예요. 사투리(DECODE·(+)·CONNECT BY)로 짜면 옮길 때마다 손이 가고요.

마지막으로 다리를 하나 놓을게요. 지난 시간에 자동 채번이 시퀀스냐 AUTO_INCREMENT 냐로 갈린다고 했죠. 이 차이는 다음 백엔드 과목에서 다시 만나요. 거기선 테이블의 자동 채번을 프로그램 객체의 식별자 전략으로 연결하는데, AUTO_INCREMENT 를 쓰면 @GeneratedValue 의 IDENTITY 전략, 시퀀스를 쓰면 SEQUENCE 전략으로 이어져요. 오늘 두 방언의 채번 차이를 잡아 둔 게, 다음 과목의 그 선택을 한결 쉽게 만들어 줘요.

💡 한 줄 정리 — 자료형·채번·행 제한·NULL·빈 문자열·날짜 포맷·연결·조건·외부 조인·계층형·집계, 이 열두 가지만 방언에 맞게 손보면 Oracle 인스타 쿼리를 MySQL 로 통째로 옮길 수 있다. 표준어로 짜 두면 옮길 게 적다.

마무리

오늘은 Oracle 로 짠 인스타 쿼리를 MySQL 8.4 로 통째로 옮겼어요. 빈 문자열과 NULL 의 미묘한 차이부터 시작해서, 날짜 포맷(DATE_FORMAT), 문자열 연결(CONCAT)과 조건 분기(CASE), 외부 조인(ANSI JOIN), 대댓글 트리(WITH RECURSIVE), 해시태그 집계(GROUP_CONCAT)까지요. 지난 시간 자료형과 채번을 옮긴 데 이어, 함수·조인·계층형이라는 더 까다로운 대목을 마저 옮겨서 인스타 쿼리를 MySQL 로 완전히 가져왔어요.

오늘 배운 핵심 세 가지

• 💡 빈 문자열 함정 — Oracle 은 '' 를 NULL 로, MySQL 은 빈 문자열로 본다. IS NULL 만으로 빈 값을 세면 두 방언에서 결과가 갈린다.
• 💡 함수·조인 방언 — TO_CHAR→DATE_FORMAT(분은 %i), ||→CONCAT(|| 는 OR), DECODE→CASE, (+)→ANSI LEFT JOIN. 표준어로 짜 두면 옮길 게 적다.
• 💡 계층형·집계 — CONNECT BY→WITH RECURSIVE(시작점 + 재귀 규칙), LISTAGG→GROUP_CONCAT(SEPARATOR·1024바이트 한도).

다음 시간 예고

이렇게 F 카테고리에서 같은 인스타그램을 Oracle 과 MySQL 두 방언으로 자유롭게 오가는 힘을 길렀어요. 그런데 데이터베이스는 지금도 계속 진화하고 있어요. 다음 시간엔 마지막으로, 요즘 데이터베이스가 어디까지 왔는지를 둘러봐요. 표(행과 열)에 딱 맞지 않는 데이터를 담는 JSON 컬럼, 그리고 SQL 표준(SQL:2023)에 새로 들어온 기능들, 나아가 이미지나 문장을 숫자 벡터로 바꿔 "비슷한 것" 을 찾는 벡터 검색까지요. 우리가 배운 관계형 SQL 이 모던 세계에서 어떻게 확장되는지를 보면서, 데이터베이스 과목을 마무리해요.

과제

오늘 옮긴 방언을 직접 손으로 다뤄 보는 과제예요. 쿼리를 실행하기 전에 결과를 먼저 예측한 뒤, MySQL 에서 실행해 맞혀 보세요.

[기초] 빈 문자열과 날짜 포맷 옮기기

(가) 자기소개(bio)가 비어 있는 회원을 MySQL 에서 세어 보세요. IS NULL 만 썼을 때와 IS NULL OR bio = '' 를 썼을 때 결과가 같은지 확인하고, 왜 Oracle 에선 둘이 항상 같은지 한 줄로 적으세요. (나) 게시물의 작성일을 2026년 06월 01일 모양으로 출력하는 쿼리를, Oracle TO_CHAR 와 MySQL DATE_FORMAT 두 가지로 각각 적으세요. (다) 작성 시각을 시:분:초 로 뽑되, 분을 %i 와 %m 으로 각각 적어 보고 결과가 어떻게 달라지는지 확인하세요.

[응용] 외부 조인과 집계 옮기기

(가) 글이 하나도 없는 회원까지 포함해 회원별 게시물 수를 MySQL LEFT JOIN 으로 구하세요. 같은 쿼리를 Oracle (+) 로는 어떻게 적을지 나란히 비교하고, 두 결과 행 수가 같은지 확인하세요. (나) 게시물별 해시태그를 GROUP_CONCAT 으로 한 줄로 모으되, 태그가 없는 게시물은 태그 없음 으로 나오게 COALESCE 를 씌우세요. (다) 같은 집계를 Oracle LISTAGG 로 적으면 어디가 달라지는지(구분자·정렬 위치) 한 줄로 정리하세요.

[심화] 대댓글 트리 직접 변환하기

(가) 게시물 1 의 대댓글 트리를 MySQL WITH RECURSIVE 로 펼쳐, 들여쓰기된 트리와 각 댓글의 깊이(lv)를 함께 출력하세요. (나) 같은 트리를 Oracle CONNECT BY 로 적을 때와 비교해, MySQL 로 옮기며 손본 세 가지(RECURSIVE 키워드·LEVEL 대체·깊이 우선 정렬)를 각각 한 줄로 설명하세요. (다) 만약 ORDER BY path 를 빼면 결과 순서가 어떻게 흐트러질지 예측해 보고, 왜 경로 문자열로 정렬해야 트리 모양이 보존되는지 생각해 보세요.

생각해볼 주제

1. 표준어로 짤까, 그 데이터베이스 사투리로 짤까

오늘 본 것처럼 CONCAT·CASE·COALESCE·ANSI JOIN 은 어디서나 통하는 표준어이고, DECODE·(+)·CONNECT BY 는 Oracle 사투리예요. 표준어로만 짜면 옮길 때 편하지만, 사투리가 더 짧거나 그 데이터베이스에 최적화돼 있을 때도 있어요. "이 서비스는 앞으로도 이 데이터베이스만 쓴다" 와 "언젠가 옮길지 모른다" 중 무엇을 가정하느냐에 따라 선택이 갈려요. 두 경우에 각각 어떤 선택이 합리적일지 견줘 보세요.

2. 빈 문자열을 NULL 로 볼 것인가, 다른 값으로 볼 것인가

Oracle 은 빈 문자열을 NULL 로 보고, MySQL 은 다른 값으로 봐요. 둘 다 나름의 일관된 철학이에요. "값이 없다는 건 빈칸이나 미입력이나 결국 같다" 는 쪽(Oracle)과 "빈칸도 엄연히 입력된 값이다" 는 쪽(MySQL)이죠. 어느 쪽이 데이터를 다루기에 더 헷갈림이 적을지, 그리고 이 차이가 두 데이터베이스를 오갈 때 왜 위험한 함정이 되는지 생각해 보세요.

3. 계층형 데이터는 데이터베이스에서 풀까, 애플리케이션에서 풀까

대댓글 트리 같은 계층형 데이터를 CONNECT BY·WITH RECURSIVE 로 데이터베이스에서 직접 펼칠 수도 있고, 평평한 댓글 목록만 가져온 뒤 프로그램 코드에서 트리로 조립할 수도 있어요. 데이터베이스에서 풀면 쿼리 한 번에 끝나지만 재귀 비용이 들고, 애플리케이션에서 풀면 데이터를 단순하게 가져오는 대신 조립 코드가 필요해요. 댓글이 얕을 때와 아주 깊을 때 각각 어느 쪽이 유리할지 떠올려 보세요.