김신건의 로그 - 위키 / sql

[SQL] Data Types

koa (김신건) — Sat, 20 Jun 2026 00:00:00 GMT

정의

SQL 의 컬럼은 타입 을 가진다. 가능한 값의 도메인, 가능한 연산, 정렬 순서, 인덱스 종류, 저장 크기가 타입에 따라 결정된다.

같은 의미의 타입도 dialect 마다 이름과 동작이 다르다. 표준 SQL 의 타입을 기준으로, [[PostgreSQL]] / [[MySQL]] 의 실용 매핑을 정리.

전체 SQL 체계는 [[SQL]] 참고.

타입 분류

그룹	주요 타입	대표 연산
숫자	`INTEGER`, `BIGINT`, `NUMERIC`, `DOUBLE`	산술, 집계, 반올림
문자열	`VARCHAR`, `TEXT`, `CHAR`	`LIKE`, 정규식, 연결, 추출
부울	`BOOLEAN`	`AND/OR/NOT`
날짜·시간	`DATE`, `TIME`, `TIMESTAMP`, `TIMESTAMPTZ`, `INTERVAL`	차이, 추출, 절단
이진	`BYTEA` (PG), `BLOB` (MySQL)	길이, 해시, 인코딩
UUID	`UUID` (PG), `BINARY(16)` / `CHAR(36)` (MySQL)	생성, 비교
화폐	`NUMERIC(p, s)`, `MONEY` (PG)	정밀 산술
JSON	`JSON`, `JSONB` (PG)	경로 추출, containment
배열	`INTEGER[]`, `TEXT[]` (PG)	슬라이싱, `ANY/ALL`, `unnest`
범위	`INT4RANGE`, `TSRANGE` (PG)	포함, 겹침
공간	`GEOMETRY`, `GEOGRAPHY` (PostGIS)	거리, 포함, 교차
열거	`ENUM` (PG/MySQL)	정렬, 비교

숫자 타입

표준 / PG	MySQL	크기	범위
`SMALLINT`	`SMALLINT`	2 B	-32,768 ~ 32,767
`INTEGER` / `INT`	`INT`	4 B	-2³¹ ~ 2³¹ - 1
`BIGINT`	`BIGINT`	8 B	-2⁶³ ~ 2⁶³ - 1
`NUMERIC(p, s)` / `DECIMAL`	`DECIMAL(p, s)`	가변	정밀 (p 자릿수, s 소수점)
`REAL` / `FLOAT4`	`FLOAT`	4 B	단정밀 부동소수
`DOUBLE PRECISION`	`DOUBLE`	8 B	배정밀 부동소수

NUMERIC vs DOUBLE

-- 화폐, 회계 → NUMERIC (정밀, 느림)
CREATE TABLE invoices (total NUMERIC(12, 2));
INSERT INTO invoices VALUES (10.10), (20.20);
SELECT SUM(total) FROM invoices;        -- 정확히 30.30

-- 과학 계산, 통계 → DOUBLE (빠름, 부동소수 오차 OK)
CREATE TABLE measurements (val DOUBLE PRECISION);
-- 0.1 + 0.2 = 0.30000000000000004

[!IMPORTANT] 돈에 FLOAT/DOUBLE 절대 금지. 누적 오차 발생.

자주 쓰는 연산

SELECT ABS(-3),                              -- 3
       CEIL(2.3), FLOOR(2.7),                -- 3, 2
       ROUND(2.345, 2),                      -- 2.35
       TRUNC(2.99),                          -- 2 (PG)
       MOD(10, 3),    10 % 3,                -- 1
       POWER(2, 10),                         -- 1024
       SQRT(16), LN(2.718), LOG(10, 1000),
       RANDOM();                             -- PG: 0~1 / MySQL: RAND()

집계 함수는 [[SQL GROUP BY]] 참고.

문자열 타입

표준	PostgreSQL	MySQL	비고
`CHARACTER(n)`	`CHAR(n)`	`CHAR(n)`	고정, 짧으면 공백 패딩
`CHARACTER VARYING(n)`	`VARCHAR(n)`	`VARCHAR(n)`	가변
`CHARACTER LARGE OBJECT`	`TEXT`	`TEXT`, `LONGTEXT`	사실상 무제한

PostgreSQL 에선 VARCHAR, TEXT, CHAR 내부 성능 동일, 길이 제약만 차이. MySQL 에선 VARCHAR 가 행 안에 저장, TEXT 는 별도 저장 영역, 성능 차이 있음.

자주 쓰는 연산

-- 길이
SELECT LENGTH('hello');                        -- 5 (PG, 문자 수)
SELECT CHAR_LENGTH('hello'), OCTET_LENGTH('한');  -- 글자 수 vs 바이트 수

-- 연결
SELECT 'Hello, ' || 'World';                   -- PG, MySQL (ANSI_MODE)
SELECT CONCAT('Hello, ', 'World');             -- 양쪽 모두

-- 자르기
SELECT SUBSTRING('hello world' FROM 7 FOR 5);  -- 'world'
SELECT SUBSTR('hello world', 7, 5);            -- 같음

-- 변환
SELECT UPPER('abc'), LOWER('ABC'), INITCAP('hello world');     -- PG
SELECT REPLACE('a-b-c', '-', '_');             -- 'a_b_c'

-- 트림
SELECT TRIM('  hello  '), LTRIM('  hello'), RTRIM('hello  ');

-- 패딩
SELECT LPAD('7', 3, '0');                      -- '007'

LIKE vs ILIKE vs 정규식

연산	의미	dialect
`LIKE '...'`	`%`, `_` 와일드카드	표준
`ILIKE '...'`	LIKE + 대소문자 무시	PostgreSQL
`~`, `~*`	정규식 (대소문자 / 무시)	PostgreSQL
`REGEXP_MATCHES`, `REGEXP_REPLACE`	정규식 함수	PostgreSQL
`REGEXP` / `RLIKE`	정규식	MySQL
`REGEXP_LIKE`, `REGEXP_SUBSTR`	정규식 함수	MySQL 8+

SELECT * FROM users WHERE name LIKE 'A%';                       -- 표준
SELECT * FROM users WHERE name ILIKE 'a%';                      -- PG
SELECT * FROM users WHERE name ~* '^a';                         -- PG 정규식
SELECT * FROM users WHERE name REGEXP '^A';                     -- MySQL

부울

-- PostgreSQL
CREATE TABLE flags (active BOOLEAN NOT NULL DEFAULT FALSE);
INSERT INTO flags VALUES (TRUE), (FALSE), (NULL);
SELECT * FROM flags WHERE active;     -- TRUE 만, NULL 제외

-- MySQL
-- BOOLEAN ≡ TINYINT(1), TRUE=1, FALSE=0
CREATE TABLE flags (active TINYINT(1) NOT NULL DEFAULT 0);
SELECT * FROM flags WHERE active = 1;

날짜·시간

가장 함정이 많은 타입. 표준 + dialect 차이가 크다.

표준 / PG	MySQL	의미
`DATE`	`DATE`	’YYYY-MM-DD’
`TIME`	`TIME`	’HH:MM:SS’ (PG: 6 자리 마이크로초)
`TIMESTAMP`	`DATETIME`	시각 (시간대 없음)
`TIMESTAMP WITH TIME ZONE` (`TIMESTAMPTZ`)	`TIMESTAMP`	시각 + UTC 변환 저장
`INTERVAL`	(없음)	기간 (예: `INTERVAL '1 day'`)

MySQL 의 TIMESTAMP

범위 1970-2038 (32-bit Unix time)
INSERT 시 세션 timezone 으로 해석 → UTC 저장 → SELECT 시 다시 세션 timezone
DATETIME 은 timezone 없음, 그대로 저장

PostgreSQL 의 TIMESTAMPTZ

항상 UTC 로 저장
표시는 세션 timezone (SET TIME ZONE 'Asia/Seoul';)
권장: 시각은 항상 TIMESTAMPTZ

현재 시각

SELECT NOW();                          -- PG: 트랜잭션 시작 시점
SELECT CURRENT_TIMESTAMP;              -- 표준
SELECT CURRENT_DATE, CURRENT_TIME;
SELECT CLOCK_TIMESTAMP();              -- PG: 진짜 wall clock
SELECT STATEMENT_TIMESTAMP();          -- PG: statement 시작 시점

MySQL: NOW(), CURRENT_TIMESTAMP(), SYSDATE() (실시간), UTC_TIMESTAMP().

산술

시간대 함정

-- PG, TIMESTAMP (timezone 없음) 에 TIMESTAMPTZ 를 넣으면 세션 timezone 으로 변환되어 저장
INSERT INTO logs (ts) VALUES ('2024-01-15 10:00 UTC');
-- 세션이 Asia/Seoul 이면 '2024-01-15 19:00' 으로 저장 (KST)

-- 권장: 항상 TIMESTAMPTZ
ALTER TABLE logs ALTER COLUMN ts TYPE TIMESTAMPTZ USING ts AT TIME ZONE 'UTC';

JSON

웹 백엔드 어디서나 만난다. 인덱싱 가능 여부가 dialect 의 가장 큰 차이.

	PostgreSQL	MySQL
타입	`JSON` (텍스트), `JSONB` (바이너리)	`JSON` (바이너리만)
인덱싱	`JSONB` GIN, expression 인덱스	generated column + 인덱스
containment `@>`	✓	✗ (대안: `JSON_CONTAINS`)
경로 추출	`->`, `->>`, `#>`, `#>>`	`->`, `->>`, `JSON_EXTRACT`

<CodeWithOutput variants={[ { language: ‘sql’, label: ‘PostgreSQL’, code: `CREATE TABLE events (id SERIAL PK, payload JSONB);

INSERT INTO events (payload) VALUES (’{“user”: 42, “tags”: [“a”,“b”], “meta”: {“ip”: “1.2.3.4”}}‘::jsonb);

— 경로 추출 SELECT payload -> ‘user’ FROM events; — 42 (jsonb) SELECT payload ->> ‘user’ FROM events; — ‘42’ (text) SELECT payload #> ‘{meta, ip}’ FROM events; — 깊은 경로 SELECT payload #>> ‘{meta, ip}’ FROM events; — ‘1.2.3.4’ (text)

— 포함 (containment) SELECT * FROM events WHERE payload @> ’{“user”: 42}’;

— 인덱스 CREATE INDEX idx_events_payload ON events USING GIN (payload); CREATE INDEX idx_events_user ON events ((payload ->> ‘user’));}, { language: 'sql', label: 'MySQL', code:CREATE TABLE events (id INT PK AUTO_INCREMENT, payload JSON);

INSERT INTO events (payload) VALUES (’{“user”: 42, “tags”: [“a”,“b”], “meta”: {“ip”: “1.2.3.4”}}’);

— 경로 추출 SELECT payload -> ‘$.user’ FROM events; — 42 SELECT payload ->> ‘$.user’ FROM events; — ‘42’ (unquote) SELECT JSON_EXTRACT(payload, ‘$.meta.ip’) FROM events; SELECT payload ->> ‘$.meta.ip’ FROM events;

— 포함 대안 SELECT * FROM events WHERE JSON_CONTAINS(payload, ‘42’, ‘$.user’);

— 인덱스 (generated column) ALTER TABLE events ADD COLUMN user_id INT GENERATED ALWAYS AS (payload ->> ‘$.user’) VIRTUAL, ADD INDEX idx_user_id (user_id); }, ]} outputLabel="비고" output={— PG 의 JSONB 는 인덱싱과 containment 가 강력 — MySQL 의 JSON 은 generated column 트릭이 필요 — JSON 에 무거운 쿼리를 자주 돌리면 별도 컬럼으로 정규화 검토`} />

JSON 의 tags 배열을 펼쳐 행으로:

-- PostgreSQL
SELECT id, tag
FROM events, jsonb_array_elements_text(payload -> 'tags') AS tag;

-- MySQL 8+
SELECT id, jt.tag
FROM events,
JSON_TABLE(payload, '$.tags[*]' COLUMNS (tag VARCHAR(50) PATH '$')) AS jt;

[[Pandas explode]] 와 같은 개념.

배열 (PostgreSQL)

CREATE TABLE posts (id SERIAL PK, tags TEXT[]);

INSERT INTO posts (tags) VALUES (ARRAY['db', 'sql']), ('{"db","cache"}');

SELECT * FROM posts WHERE tags @> ARRAY['db'];                    -- 포함
SELECT * FROM posts WHERE 'sql' = ANY(tags);                       -- 멤버
SELECT array_length(tags, 1) FROM posts;                           -- 길이
SELECT id, t FROM posts, unnest(tags) AS t;                        -- 펼침

CREATE INDEX idx_posts_tags ON posts USING GIN (tags);

MySQL 에는 배열 타입이 없다, 보통 JSON 으로 흉내.

UUID

-- PostgreSQL
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
CREATE TABLE users (id UUID PRIMARY KEY DEFAULT uuid_generate_v4());

-- MySQL 8+
CREATE TABLE users (id BINARY(16) PRIMARY KEY DEFAULT (UUID_TO_BIN(UUID())));

UUID v4 (랜덤) 는 인덱스 지역성이 나쁘다. 시간 정렬 UUID (v7, ULID) 가 B-tree 친화적.

ENUM

-- PostgreSQL
CREATE TYPE order_status AS ENUM ('pending', 'paid', 'shipped', 'cancelled');
ALTER TABLE orders ADD COLUMN status order_status;
ALTER TYPE order_status ADD VALUE 'refunded';     -- 추가
-- 값 제거는 직접 불가, 우회 필요

-- MySQL
CREATE TABLE orders (
  ...,
  status ENUM('pending', 'paid', 'shipped', 'cancelled')
);
ALTER TABLE orders MODIFY COLUMN status
  ENUM('pending', 'paid', 'shipped', 'cancelled', 'refunded');     -- 풀 리라이트

ENUM 은 추가는 쉬워도 변경/제거가 까다롭다. 상태가 자주 변하면 lookup 테이블 + FK 가 더 유연.

타입 변환 (CAST)

SELECT CAST('42' AS INTEGER);
SELECT '42'::INTEGER;     -- PostgreSQL 단축

-- 안전한 변환 (실패 시 NULL, PG 17+)
SELECT CAST('abc' AS INTEGER ON ERROR NULL);
-- 또는 사용자 함수, TRY_CAST 같은 패턴

-- TO_CHAR / TO_DATE / TO_NUMBER (PG, Oracle 영향)
SELECT TO_CHAR(NOW(), 'YYYY-MM-DD HH24:MI');
SELECT TO_DATE('2024-01-15', 'YYYY-MM-DD');

[!CAUTION] 묵시적 형변환은 인덱스를 깬다. WHERE id = '42' 가 id 가 정수면 양쪽 모두 INTEGER 로 변환, 인덱스 OK. 하지만 WHERE CAST(id AS TEXT) = '42' 는 인덱스 못 쓴다.

pandas 와 타입 대응

SQL	pandas	dtype
`INTEGER`, `BIGINT`	`int64`, `Int64` (nullable)	int
`NUMERIC`	`Decimal` (object) 또는 `float64`	object/float
`DOUBLE`	`float64`	float
`BOOLEAN`	`bool`, `boolean` (nullable)	bool
`VARCHAR`, `TEXT`	`object`, `string`	string
`DATE`	`datetime64[ns]` (또는 `datetime64[ns, tz]`)	datetime
`TIMESTAMP`	`datetime64[ns]`	datetime
`TIMESTAMPTZ`	`datetime64[ns, UTC]`	datetime tz-aware
`INTERVAL`	`timedelta64[ns]`	timedelta
`JSON`, `JSONB`	`object` (dict)	object
`ARRAY`	`object` (list)	object
`UUID`	`object` (str)	object

DB 와 DataFrame 의 타입 매핑은 [[Pandas read_sql]] 의 dtype_backend, parse_dates, dtype= 옵션 참고.

[[Pandas nullable]] (Int64, boolean) 가 NULL 을 정수/부울에 보존하기 위해 도입되었다.

함정

1. VARCHAR(N) 의 N

PG: 글자 수, 초과 시 에러
MySQL: 글자 수, 초과 시 에러 (strict_mode) 또는 잘림 (non_strict)
인코딩 (utf8mb4) 차이로 바이트 길이 ≠ 글자 수

2. TIMESTAMP vs TIMESTAMPTZ

PG 에서 TIMESTAMP 와 TIMESTAMPTZ 는 다른 타입. 운영에서 시각은 항상 TIMESTAMPTZ.

3. NUMERIC 의 정밀도

NUMERIC(10, 2)     -- 전체 10 자리, 소수점 이하 2 자리
-- 정수부 최대 8 자리, 99999999.99 까지

4. FLOAT 의 비교

SELECT 0.1::FLOAT + 0.2::FLOAT = 0.3::FLOAT;     -- FALSE!
-- 같음 비교는 위험, ABS(a - b) < epsilon

5. NULL 의 정렬

ORDER BY salary DESC NULLS LAST     -- PG (표준)
ORDER BY salary IS NULL, salary DESC     -- MySQL 우회

6. 묵시적 변환 (MySQL)

-- MySQL: 문자열 ↔ 숫자 묵시적 변환
SELECT '1' + 1;          -- 2
SELECT '1a' + 1;         -- 2 (경고만)
SELECT 'a' + 1;          -- 1 (조용히 0 으로 변환!)

PG 는 같은 케이스에서 에러. 둘 다 운영 코드에선 명시적 변환 권장.

[SQL] DCL TCL

koa (김신건) — Sat, 20 Jun 2026 00:00:00 GMT

정의

DCL (Data Control Language): 권한. GRANT, REVOKE.
TCL (Transaction Control Language): 트랜잭션 경계. BEGIN, COMMIT, ROLLBACK, SAVEPOINT.

같이 묶어 다루는 이유, “보안”과 “원자성”은 운영의 두 기둥이고 SQL 의 나머지 (DDL/DML) 와 결이 다르다.

전체 SQL 체계는 [[SQL]] 참고.

트랜잭션과 ACID

트랜잭션 = 하나의 논리 단위로 묶인 SQL 문 집합. 전체가 성공하거나 (COMMIT), 전체가 취소되거나 (ROLLBACK).

성질	의미
Atomicity	원자성, all-or-nothing
Consistency	무결성 제약을 깨지 않음
Isolation	동시 트랜잭션이 서로 안 보임 (격리 수준 따라)
Durability	커밋된 변경은 영구 (장애에도 살아남음)

Redis 의 트랜잭션은 ACID 가 아니다, 자세한 비교는 [[Redis]] 참고.

BEGIN / COMMIT / ROLLBACK

BEGIN;       -- 트랜잭션 시작 (PG)
START TRANSACTION;   -- 표준 / MySQL

UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;

COMMIT;     -- 확정
-- 또는
ROLLBACK;   -- 취소, 둘 다 안 일어난 상태로

[!IMPORTANT]

PostgreSQL: 모든 statement 가 암묵적 트랜잭션. BEGIN 명시하면 다중 statement 트랜잭션.

MySQL: autocommit=1 (기본). statement 마다 자동 커밋. BEGIN/START TRANSACTION 으로 묶거나 SET autocommit=0 후 명시 COMMIT.

autocommit 의 함정

-- MySQL 기본 (autocommit=1)
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
-- 즉시 커밋, 되돌릴 수 없음!

-- 안전한 방법
START TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
SELECT balance FROM accounts WHERE id = 1;     -- 확인
COMMIT;        -- 또는 ROLLBACK

운영 DB 에선 항상 명시적 트랜잭션. autocommit 끄는 습관 권장.

SAVEPOINT

트랜잭션 안에서 부분 롤백 지점.

BEGIN;

INSERT INTO logs (msg) VALUES ('start');

SAVEPOINT before_risky;

UPDATE inventory SET qty = qty - 5 WHERE id = 1;
-- 이상 발견
ROLLBACK TO SAVEPOINT before_risky;
-- start log 는 살아 있고 inventory 변경만 취소

INSERT INTO logs (msg) VALUES ('skipped risky op');

COMMIT;

격리 수준 (Isolation Level)

동시 트랜잭션 간 가시성. ANSI 표준 4 단계.

수준	Dirty Read	Non-repeatable Read	Phantom Read
READ UNCOMMITTED	가능	가능	가능
READ COMMITTED	방지	가능	가능
REPEATABLE READ	방지	방지	가능 (표준), 방지 (PG, MySQL InnoDB)
SERIALIZABLE	방지	방지	방지

이상현상	의미
Dirty Read	커밋 안 된 데이터 읽음
Non-repeatable Read	같은 쿼리 두 번 → 다른 값
Phantom Read	같은 쿼리 두 번 → 새로 추가된 행 보임

dialect 기본값

PostgreSQL: READ COMMITTED 기본. REPEATABLE READ, SERIALIZABLE 사용 가능 (MVCC + SSI).
MySQL InnoDB: REPEATABLE READ 기본. Phantom 도 방지 (gap lock).

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN;
-- ...
COMMIT;

MVCC, 잠금, 비교

잠금 기반 (Lock-based): 읽는 동안 쓰기 차단. 단순하지만 짧은 쓰기에도 읽기가 막힘.
MVCC (Multi-Version Concurrency Control): 트랜잭션마다 자기 버전의 스냅샷을 본다. 읽기가 쓰기를 막지 않고, 쓰기가 읽기를 막지 않는다. PostgreSQL, MySQL InnoDB, Oracle 의 기본.

-- 명시적 행 잠금
SELECT * FROM accounts WHERE id = 1 FOR UPDATE;     -- 쓰기 잠금
SELECT * FROM accounts WHERE id = 1 FOR SHARE;      -- 읽기 잠금

-- PG: 다른 트랜잭션 락 충돌 시 즉시 에러
SELECT * FROM accounts WHERE id = 1 FOR UPDATE NOWAIT;
SELECT * FROM accounts WHERE id = 1 FOR UPDATE SKIP LOCKED;     -- 큐 패턴

데드락

서로의 락을 기다리는 두 트랜잭션. RDBMS 가 감지해서 한쪽을 강제 롤백.

T1: UPDATE a; UPDATE b;
T2: UPDATE b; UPDATE a;
   → T1 이 a 잠그고 b 대기, T2 가 b 잠그고 a 대기 → deadlock

해법: 항상 같은 순서로 락 획득, 또는 짧은 트랜잭션 유지, 또는 비관적 잠금 → 낙관적 잠금 (version 컬럼).

DCL: GRANT / REVOKE

권한 부여/회수.

사용자/역할

-- PostgreSQL
CREATE USER alice WITH PASSWORD 'secret';
CREATE ROLE app_reader;
GRANT app_reader TO alice;

-- MySQL
CREATE USER 'alice'@'%' IDENTIFIED BY 'secret';
CREATE ROLE 'app_reader';
GRANT 'app_reader' TO 'alice'@'%';

PG 는 USER 와 ROLE 이 같은 개념 (USER 는 LOGIN 권한이 있는 ROLE), MySQL 도 8.0 부터 통합.

권한 부여

-- 테이블 단위
GRANT SELECT, INSERT ON users TO alice;
GRANT ALL PRIVILEGES ON orders TO alice;

-- 스키마 단위 (PostgreSQL)
GRANT USAGE ON SCHEMA public TO alice;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO alice;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO alice;     -- 미래 테이블도 자동 적용

-- 데이터베이스 단위 (MySQL)
GRANT SELECT, INSERT ON mydb.* TO 'alice'@'%';

-- 모든 데이터베이스 (위험)
GRANT ALL PRIVILEGES ON *.* TO 'alice'@'%' WITH GRANT OPTION;

컬럼 단위 권한

GRANT SELECT (id, name) ON users TO alice;     -- 일부 컬럼만

salary 같은 민감 컬럼은 컬럼 단위 + 뷰로 격리하는 게 더 흔하다.

REVOKE

REVOKE INSERT ON users FROM alice;
REVOKE ALL PRIVILEGES ON users FROM alice;

권한 확인

-- PostgreSQL
\dp users
SELECT * FROM information_schema.table_privileges WHERE grantee = 'alice';

-- MySQL
SHOW GRANTS FOR 'alice'@'%';

RLS (Row Level Security, PostgreSQL)

행 단위 권한, 같은 테이블이라도 사용자에 따라 보이는 행이 다르다.

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY owner_only ON orders
  FOR SELECT
  USING (user_id = current_setting('app.user_id')::int);

세션 변수로 사용자 컨텍스트를 주고 RLS 가 자동으로 WHERE 추가. 멀티테넌트 SaaS 의 강력한 패턴.

MySQL 은 RLS 가 없다, 뷰 + 권한으로 흉내 또는 애플리케이션 레벨.

트랜잭션과 DDL

dialect 큰 차이.

	PostgreSQL	MySQL
`CREATE TABLE` 트랜잭션 안	롤백 가능	묵시적 커밋 (롤백 불가)
`ALTER TABLE` 트랜잭션 안	롤백 가능	8.0 의 일부 atomic DDL 외엔 묵시적 커밋
`TRUNCATE`	롤백 가능	묵시적 커밋

PostgreSQL 마이그레이션 스크립트는 전부 한 트랜잭션 으로 묶을 수 있다, MySQL 은 중간에 멈추면 부분 적용 상태가 남는다.

2-Phase Commit (분산 트랜잭션)

여러 노드에 걸친 트랜잭션. PG PREPARE TRANSACTION / COMMIT PREPARED.

BEGIN;
UPDATE ...;
PREPARE TRANSACTION 'tx1';     -- 모든 노드가 prepare 성공이면

COMMIT PREPARED 'tx1';
-- 한 노드라도 실패면
ROLLBACK PREPARED 'tx1';

운영에선 거의 안 쓴다 (느림, 잠금 길게 유지, 코디네이터 SPOF). Saga 패턴 등 분산 트랜잭션 대안 검토.

pandas 와 트랜잭션

pandas 자체는 트랜잭션 개념이 없다. DB I/O 시 SQLAlchemy 의 connection 컨텍스트가 트랜잭션 역할.

from sqlalchemy import create_engine, text
engine = create_engine('postgresql://...')

with engine.begin() as conn:        # 컨텍스트 종료 시 자동 commit, 예외 시 rollback
    df1.to_sql('a', conn, if_exists='append', index=False)
    df2.to_sql('b', conn, if_exists='append', index=False)
# 둘 다 성공해야 commit, 한쪽 실패면 둘 다 rollback

자세한 [[Pandas read_sql]] 패턴 참고.

함정

1. 트랜잭션 너무 길게

대용량 UPDATE 를 한 트랜잭션에 넣으면:

락 점유 길어짐 → 동시성 저하
WAL/redo log 부피 증가
롤백 시간 길어짐 (PG 의 dead tuple 누적)

→ 청크 단위 배치, 짧은 트랜잭션 다발.

2. SELECT 결과의 즉시성

SELECT COUNT(*) FROM t WHERE x = 1;     -- 100
-- 다른 트랜잭션이 INSERT
SELECT COUNT(*) FROM t WHERE x = 1;     -- 격리 수준에 따라 100 또는 101

REPEATABLE READ 면 같은 트랜잭션 내내 100, READ COMMITTED 면 변할 수 있다.

3. 데드락은 정상

운영 DB 에서 데드락은 발생한다, RDBMS 가 감지하고 롤백. 애플리케이션은 재시도 로직 을 가져야 한다.

for attempt in range(3):
    try:
        with engine.begin() as conn:
            do_work(conn)
        break
    except DeadlockError:
        time.sleep(0.1 * (2 ** attempt))

4. 권한 누락

GRANT SELECT ON ALL TABLES IN SCHEMA public TO alice;
-- 이후 새로 만든 테이블에는 권한 없음
-- → ALTER DEFAULT PRIVILEGES 같이

5. GRANT OPTION 의 전파

GRANT SELECT ON users TO alice WITH GRANT OPTION;
-- alice 가 또 다른 사용자에게 GRANT 가능
-- 추적 어려워짐, 운영에선 신중히

6. 최소 권한 원칙

운영 앱 계정은 보통:

DDL 권한 없음 (CREATE/DROP)
SELECT/INSERT/UPDATE/DELETE 만, 필요한 테이블에만
슈퍼유저는 마이그레이션 도구 전용 분리

[SQL] DDL

koa (김신건) — Sat, 20 Jun 2026 00:00:00 GMT

정의

DDL (Data Definition Language) 은 스키마를 정의/변경/제거 하는 SQL 의 하위 집합. 대상은 테이블, 인덱스, 뷰, 시퀀스, 스키마, 도메인 등.

대부분의 DDL 은 DDL 자체가 한 트랜잭션 으로 묶이고 (PostgreSQL 은 트랜잭션 안에서 롤백 가능, MySQL 8.0 의 일부 DDL 은 atomic), 자주 일어나지 않는다. 자주 일어나는 건 DML.

전체 SQL 체계는 [[SQL]] 참고.

핵심 키워드

명령	의미
`CREATE`	새 객체 생성
`ALTER`	기존 객체 수정
`DROP`	객체 제거
`TRUNCATE`	테이블 데이터 전부 제거 (구조 유지, 빠름)
`RENAME`	이름 변경
`COMMENT`	메타데이터 코멘트 (PG/MySQL 지원)

CREATE TABLE 기본

<CodeWithOutput language=“sql” outputLanguage=“text” code={`CREATE TABLE users ( id SERIAL PRIMARY KEY, email VARCHAR(255) NOT NULL UNIQUE, name VARCHAR(50) NOT NULL, age INTEGER CHECK (age >= 0), city VARCHAR(30) DEFAULT ‘Seoul’, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP );

\d users} output={ Table “public.users” Column | Type | Modifiers ------------+---------------+------------------ id | integer | not null PK email | varchar(255) | not null UNIQUE name | varchar(50) | not null age | integer | CHECK (age >= 0) city | varchar(30) | default ‘Seoul’ created_at | timestamp | not null default now()`} />

제약조건 (Constraints)

제약	의미	예
`NOT NULL`	NULL 금지	`name VARCHAR(50) NOT NULL`
`UNIQUE`	중복 금지 (단일/복합)	`email VARCHAR(255) UNIQUE`
`PRIMARY KEY`	NOT NULL + UNIQUE + 테이블당 하나	`id INTEGER PRIMARY KEY`
`FOREIGN KEY`	다른 테이블 PK 참조	아래 예
`CHECK`	사용자 정의 조건	`CHECK (age >= 0)`
`DEFAULT`	기본값	`DEFAULT 'Seoul'`

복합 키 / 외래 키

CREATE TABLE order_items (
  order_id   INTEGER NOT NULL,
  product_id INTEGER NOT NULL,
  qty        INTEGER NOT NULL CHECK (qty > 0),
  PRIMARY KEY (order_id, product_id),
  FOREIGN KEY (order_id)   REFERENCES orders(id)   ON DELETE CASCADE,
  FOREIGN KEY (product_id) REFERENCES products(id) ON DELETE RESTRICT
);

ON DELETE 옵션:

CASCADE: 부모 삭제 시 자식도 삭제
RESTRICT / NO ACTION: 자식이 있으면 부모 삭제 거부 (기본)
SET NULL: 자식의 FK 를 NULL 로
SET DEFAULT: 자식의 FK 를 DEFAULT 로

명명된 제약

CREATE TABLE accounts (
  id      INTEGER,
  balance INTEGER,
  CONSTRAINT pk_accounts        PRIMARY KEY (id),
  CONSTRAINT ck_balance_nonneg  CHECK (balance >= 0)
);

ALTER TABLE accounts DROP CONSTRAINT ck_balance_nonneg;

이름을 주면 ALTER 로 핀포인트 변경이 가능하다.

자동 증가 PK, dialect 차이

같은 의미, 문법은 dialect 마다 다르다.

dialect 별 자세한 비교는 [[PostgreSQL]], [[MySQL]].

ALTER TABLE

컬럼 추가/삭제/수정

-- 컬럼 추가
ALTER TABLE users ADD COLUMN phone VARCHAR(20);

-- 컬럼 삭제
ALTER TABLE users DROP COLUMN phone;

-- 타입 변경 (PostgreSQL)
ALTER TABLE users ALTER COLUMN age TYPE BIGINT;
ALTER TABLE users ALTER COLUMN age TYPE BIGINT USING age::BIGINT;

-- 타입 변경 (MySQL)
ALTER TABLE users MODIFY COLUMN age BIGINT;
ALTER TABLE users CHANGE COLUMN age years BIGINT;  -- 이름까지 변경

-- 컬럼 이름 변경 (PostgreSQL)
ALTER TABLE users RENAME COLUMN age TO years;

-- DEFAULT 변경
ALTER TABLE users ALTER COLUMN city SET DEFAULT 'Busan';
ALTER TABLE users ALTER COLUMN city DROP DEFAULT;

-- NOT NULL 제약 추가/제거
ALTER TABLE users ALTER COLUMN name SET NOT NULL;
ALTER TABLE users ALTER COLUMN name DROP NOT NULL;

제약조건 추가/제거

ALTER TABLE users ADD CONSTRAINT uq_users_email UNIQUE (email);
ALTER TABLE users ADD CONSTRAINT fk_users_dept
  FOREIGN KEY (dept_id) REFERENCES departments(id);

ALTER TABLE users DROP CONSTRAINT uq_users_email;

테이블 이름 변경

ALTER TABLE users RENAME TO members;

큰 테이블에서 주의

[!CAUTION] 큰 테이블 (수억 행) 에서 ALTER 는 테이블 락을 잡고 풀 리라이트가 일어날 수 있다.

PostgreSQL 은 11+ 부터 일부 ADD COLUMN ... DEFAULT 가 즉시 메타데이터만 변경.

MySQL 8.0 의 INSTANT 알고리즘: ALGORITHM=INSTANT, LOCK=NONE.

그 외엔 pt-online-schema-change, gh-ost, pg-osc 같은 온라인 마이그레이션 도구 사용.

DROP TABLE

DROP TABLE users;
DROP TABLE IF EXISTS users;
DROP TABLE users CASCADE;     -- 의존 객체 (FK, 뷰) 까지 함께 삭제

CASCADE 는 위험하다. 의도가 명확할 때만.

TRUNCATE

데이터는 다 지우되 테이블 구조는 유지. DELETE 보다 훨씬 빠르다 (행 단위 로깅 없이 페이지 단위 정리).

TRUNCATE TABLE events;
TRUNCATE TABLE events RESTART IDENTITY;    -- 시퀀스도 리셋 (PG)
TRUNCATE TABLE events CASCADE;             -- FK 참조 자식까지 (PG)

[!IMPORTANT]

TRUNCATE 는 DDL 이라 트랜잭션 안에서 롤백 동작이 dialect 마다 다르다 (PG: OK, MySQL: 묵시적 커밋).

트리거가 안 걸린다 (행 단위 이벤트가 발생 안 함).

CREATE INDEX

조회 성능을 위해. PK/UNIQUE 는 자동 인덱스 생성.

-- 단일 컬럼
CREATE INDEX idx_users_email ON users(email);

-- 복합 (순서 중요, 좌측 prefix 부터 사용 가능)
CREATE INDEX idx_orders_user_date ON orders(user_id, created_at DESC);

-- UNIQUE
CREATE UNIQUE INDEX ux_users_email ON users(email);

-- 부분 인덱스 (PostgreSQL)
CREATE INDEX idx_orders_active ON orders(user_id) WHERE status = 'active';

-- 표현식 인덱스
CREATE INDEX idx_users_lower_email ON users(LOWER(email));

-- 동시 생성 (락 최소화, PostgreSQL)
CREATE INDEX CONCURRENTLY idx_huge ON big_table(key);

인덱스 종류	용도	dialect
B-tree (기본)	등호, 범위, ORDER BY	모든 RDBMS
Hash	등호만	PG (디스크), MySQL Memory engine
GIN	다값 (JSONB, 배열, 풀텍스트)	PostgreSQL
GiST	공간, 범위	PostgreSQL
BRIN	거대 테이블 + 물리적 클러스터링	PostgreSQL
Full-text	자연어 검색	PG (`tsvector`), MySQL (`FULLTEXT`)

인덱스가 효과 없는 경우

컬럼에 함수 적용: WHERE LOWER(name) = 'alice' → 표현식 인덱스 필요
LIKE '%xxx' (앞에 와일드카드) → reverse 인덱스 또는 trigram (pg_trgm)
카디널리티 매우 낮을 때 (성별 1/2) → 옵티마이저가 풀 스캔 선택
데이터 변환: WHERE CAST(id AS TEXT) = '1' → 형변환 인덱스 깨짐

CREATE VIEW

쿼리를 이름 붙여 재사용. 뷰는 저장된 SELECT, 데이터를 따로 가지지 않는다.

CREATE VIEW active_users AS
SELECT id, name, email
FROM users
WHERE status = 'active';

SELECT * FROM active_users;     -- 일반 테이블처럼 사용

머티리얼라이즈드 뷰 (Materialized View)

결과를 실제로 저장. 빠르지만 갱신이 필요.

-- PostgreSQL
CREATE MATERIALIZED VIEW user_stats AS
SELECT city, COUNT(*) AS cnt, AVG(salary) AS avg_sal
FROM users
GROUP BY city;

REFRESH MATERIALIZED VIEW user_stats;
REFRESH MATERIALIZED VIEW CONCURRENTLY user_stats;  -- 잠금 최소화 (UNIQUE 인덱스 필요)

MySQL 은 기본 머티리얼라이즈드 뷰가 없다, 직접 테이블 + 트리거/스케줄로 구현.

CREATE SCHEMA

논리 네임스페이스.

CREATE SCHEMA analytics;
CREATE TABLE analytics.events (...);
SET search_path TO analytics, public;     -- PostgreSQL

MySQL 은 SCHEMA 와 DATABASE 가 동의어. PostgreSQL 은 데이터베이스 안에 여러 스키마.

SEQUENCE (PostgreSQL)

CREATE SEQUENCE order_seq START 1000 INCREMENT 1;

INSERT INTO orders (id, ...) VALUES (NEXTVAL('order_seq'), ...);
SELECT CURRVAL('order_seq');
SELECT SETVAL('order_seq', 5000);

MySQL 은 시퀀스가 없고 AUTO_INCREMENT 만 있다.

CREATE TRIGGER

-- PostgreSQL
CREATE OR REPLACE FUNCTION update_modified()
RETURNS TRIGGER AS $$
BEGIN
  NEW.modified_at := NOW();
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trg_users_modified
BEFORE UPDATE ON users
FOR EACH ROW EXECUTE FUNCTION update_modified();

-- MySQL
CREATE TRIGGER trg_users_modified
BEFORE UPDATE ON users
FOR EACH ROW
SET NEW.modified_at = NOW();

pandas 와 SQL DDL

pandas 는 DDL 이 거의 필요 없다. DataFrame 의 컬럼 = SQL 의 컬럼, dtype = SQL 의 컬럼 타입, 자동으로 추론된다.

SQL DDL	pandas 대응
`CREATE TABLE`	`pd.DataFrame({...})`
`ALTER TABLE ADD COLUMN`	`df['new_col'] = ...`
`ALTER TABLE DROP COLUMN`	`df.drop(columns=['col'])`
`ALTER COLUMN TYPE`	`df['col'].astype(...)`
`DROP TABLE`	`del df`
`TRUNCATE`	`df.drop(df.index)` / `df.iloc[0:0]`
`INDEX`	`df.set_index(...)` (개념적, 성능적으로 다름)

DB 에 DataFrame 을 쓸 때는 [[Pandas read_sql]] 의 to_sql(dtype=...) 로 타입 명시.

함정

1. CASCADE 의 폭발성

DROP TABLE users CASCADE;
-- users 를 참조하는 모든 FK 테이블, 뷰, 함수가 사라질 수 있다

운영 환경에선 CASCADE 보다 의존성 파악 후 단계적 DROP.

2. 큰 테이블의 ALTER

수억 행 테이블에 ADD COLUMN ... NOT NULL DEFAULT ... 는 전부 리라이트. 단계적으로:

NULL 허용 컬럼 추가
배치로 백필
NOT NULL 제약 추가

PG 11+ / MySQL 8.0 에선 일부 메타데이터만 바꾸는 INSTANT 가능.

3. 인덱스 너무 많이

INSERT/UPDATE/DELETE 가 모든 인덱스를 갱신. 인덱스 1 개 추가 = 쓰기 비용 증가. 실제 쿼리 plan 보고 결정.

4. CHAR vs VARCHAR

CHAR(N): 고정 길이, 짧으면 공백 패딩
VARCHAR(N): 가변 길이, 길이 제한
TEXT (PG) / LONGTEXT (MySQL): 사실상 무제한

PostgreSQL 은 VARCHAR 와 TEXT 의 내부 표현이 같다, 길이 제한 외엔 성능 차이 없음. 일반적으로 TEXT 권장.

[SQL] DML

koa (김신건) — Sat, 20 Jun 2026 00:00:00 GMT

정의

DML (Data Manipulation Language) 은 데이터 자체를 조회/삽입/수정/삭제 하는 SQL 의 하위 집합. 일상 쿼리의 99% 가 여기에 속한다.

명령	의미
`SELECT`	데이터 조회
`INSERT`	새 행 삽입
`UPDATE`	기존 행 수정
`DELETE`	행 삭제
`MERGE`	UPSERT (표준), dialect 마다 대안

전체 SQL 체계는 [[SQL]] 참고. 스키마 정의는 [[SQL DDL]], 권한·트랜잭션은 [[SQL DCL TCL]].

SELECT, 전체 골격

SELECT [DISTINCT] 컬럼1, 컬럼2, 표현식 AS alias
FROM 테이블 [AS] 별칭
[JOIN ...]                  -- 결합
[WHERE  조건]               -- 행 필터
[GROUP BY 컬럼]              -- 그룹 분할
[HAVING 그룹조건]            -- 그룹 필터
[ORDER BY 컬럼 [ASC|DESC]]  -- 정렬
[LIMIT n [OFFSET m]];       -- 페이징

논리적 실행 순서는 [[SQL]] 의 “쿼리 실행의 논리적 순서” 참고.

SELECT 기본 예제

<CodeWithOutput language=“sql” outputLanguage=“text” code={`— 전체 SELECT * FROM users;

— 컬럼 선택 + 별칭 SELECT id, name AS user_name, salary * 12 AS yearly FROM users;

— 필터 + 정렬 + 페이징 SELECT name, salary FROM users WHERE city = ‘Seoul’ AND salary >= 3000 ORDER BY salary DESC LIMIT 5;

— 중복 제거 SELECT DISTINCT city FROM users;} output={— users 전체 id | name | city | salary ----+---------+-------+-------- 1 | Alice | Seoul | 3000 2 | Bob | Busan | 4000 3 | Charlie | Seoul | 3500

— Seoul + 3000 이상, 내림차순 name | salary ---------+-------- Charlie | 3500 Alice | 3000`} />

WHERE 의 연산자

연산	의미
`=`, `<>` (`!=`), `<`, `<=`, `>`, `>=`	비교
`AND`, `OR`, `NOT`	부울
`BETWEEN a AND b`	`>= a AND <= b`
`IN (...)`	집합 멤버
`LIKE` / `ILIKE` (PG)	패턴 (`%`, `_`)
`IS NULL` / `IS NOT NULL`	NULL 검사
`EXISTS (subquery)`	결과 존재 여부

[!IMPORTANT] NULL 비교는 = 가 안 통한다. WHERE col = NULL 은 항상 거짓. WHERE col IS NULL 을 써야 한다. [[SQL]] 의 “NULL 의 3-값 논리” 참고.

LIKE 패턴

WHERE name LIKE 'A%'      -- A 로 시작
WHERE name LIKE '%son'    -- son 으로 끝
WHERE name LIKE '_lice'   -- 한 글자 + lice
WHERE name LIKE '%50\\%%' ESCAPE '\\'   -- 리터럴 % 검색

SELECT 표현식

산술, 문자열, 날짜 함수, CASE WHEN. 자세한 타입별 연산은 [[SQL Data Types]] 참고.

SELECT
  name,
  salary,
  salary * 12               AS yearly,
  CASE
    WHEN salary >= 4000 THEN 'high'
    WHEN salary >= 3000 THEN 'mid'
    ELSE                     'low'
  END AS tier,
  EXTRACT(YEAR FROM created_at) AS join_year
FROM users;

ORDER BY 의 디테일

ORDER BY salary DESC                          -- 단일 컬럼
ORDER BY city ASC, salary DESC                -- 여러 컬럼
ORDER BY 2 DESC                               -- SELECT 절 N 번째 컬럼 (가독성 나쁨)
ORDER BY salary DESC NULLS LAST               -- NULL 위치 지정 (PG 표준)

dialect 차이:

PostgreSQL: 기본 NULLS LAST for DESC, NULLS FIRST for ASC. 명시 가능.
MySQL: 기본 NULLS FIRST. NULLS LAST 미지원, ORDER BY col IS NULL, col 우회.

LIMIT / OFFSET 의 함정

SELECT * FROM events ORDER BY id LIMIT 20 OFFSET 1000000;

OFFSET 은 스킵하기 위해 그 행들을 다 읽는다. 깊은 페이지에서 매우 느림.

해법: Keyset Pagination (cursor).

-- 첫 페이지
SELECT * FROM events WHERE id > 0 ORDER BY id LIMIT 20;
-- 다음 페이지: 마지막 id 를 cursor 로
SELECT * FROM events WHERE id > 12345 ORDER BY id LIMIT 20;

서브쿼리

스칼라 서브쿼리

SELECT
  name,
  salary,
  (SELECT AVG(salary) FROM users) AS overall_avg
FROM users;

IN / EXISTS

SELECT name FROM users
WHERE id IN (SELECT user_id FROM orders WHERE amount > 1000);

SELECT name FROM users u
WHERE EXISTS (
  SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.amount > 1000
);

옵티마이저는 보통 EXISTS 가 더 빠르다 (첫 매칭에서 짧게 끊음). IN 은 결과 집합 전체를 만든다.

상관 서브쿼리 (Correlated)

SELECT name,
  (SELECT MAX(amount) FROM orders o WHERE o.user_id = u.id) AS max_order
FROM users u;

외부 쿼리의 행마다 내부 쿼리가 실행, 비용 큼. JOIN 으로 풀 수 있는지 검토.

CTE (Common Table Expression)

WITH 절로 이름 붙인 임시 결과셋. 가독성 + 재사용.

WITH high_paid AS (
  SELECT id, name FROM users WHERE salary >= 4000
),
their_orders AS (
  SELECT u.name, o.amount
  FROM high_paid u
  JOIN orders o ON o.user_id = u.id
)
SELECT name, SUM(amount) AS total
FROM their_orders
GROUP BY name;

PG 12+, MySQL 8+ 에서 잘 동작. 옵티마이저가 inline 화 (PG 12+) 또는 머티리얼라이즈 (PG 11-).

재귀 CTE

WITH RECURSIVE category_tree AS (
  SELECT id, parent_id, name, 1 AS depth
  FROM categories
  WHERE parent_id IS NULL
  UNION ALL
  SELECT c.id, c.parent_id, c.name, ct.depth + 1
  FROM categories c
  JOIN category_tree ct ON c.parent_id = ct.id
)
SELECT * FROM category_tree ORDER BY depth, name;

조직도, 카테고리, BFS/DFS 트리 순회에.

INSERT

단일/다중 행

INSERT INTO users (name, city, salary) VALUES ('Alice', 'Seoul', 3000);

INSERT INTO users (name, city, salary) VALUES
  ('Alice',   'Seoul', 3000),
  ('Bob',     'Busan', 4000),
  ('Charlie', 'Seoul', 3500);

INSERT … SELECT

INSERT INTO users_backup (id, name, city, salary)
SELECT id, name, city, salary FROM users WHERE created_at < '2024-01-01';

RETURNING (PostgreSQL)

INSERT/UPDATE/DELETE 의 결과를 즉시 반환. 자동 생성된 PK 받기에 좋다.

INSERT INTO users (name, city, salary)
VALUES ('Diana', 'Seoul', 3200)
RETURNING id, created_at;

MySQL 은 RETURNING 미지원. LAST_INSERT_ID() 함수로 마지막 PK 만 조회 가능. MariaDB 는 지원.

UPDATE

UPDATE users
SET salary = salary * 1.1,
    updated_at = NOW()
WHERE city = 'Seoul';

다른 테이블 참조해서 UPDATE

WHERE 없는 UPDATE 의 무서움

UPDATE users SET salary = 0;     -- ⚠️ 전체 행 갱신!

운영 DB 에선 항상 BEGIN → SELECT 로 검증 → UPDATE → COMMIT 의 흐름. [[SQL DCL TCL]] 참고.

DELETE

DELETE FROM users WHERE id = 5;
DELETE FROM users WHERE created_at < '2020-01-01';

다른 테이블 참조해서 DELETE

-- PostgreSQL
DELETE FROM users u
USING blacklist b
WHERE u.email = b.email;

-- MySQL
DELETE u FROM users u
JOIN blacklist b ON u.email = b.email;

DELETE vs TRUNCATE

	DELETE	TRUNCATE
구분	DML	DDL
WHERE	✓	✗ (전체만)
트리거	동작	동작 안 함
시퀀스 리셋	✗	옵션 (PG)
속도	행 단위, 느림	페이지 단위, 빠름
FK	RESTRICT 가능	CASCADE 필요
트랜잭션 롤백	가능	dialect 따라

UPSERT, dialect 차이

같은 키가 있으면 UPDATE, 없으면 INSERT.

pandas 와 DML 의 대응

SQL	pandas
`SELECT * FROM t`	`df`
`SELECT col FROM t`	`df[['col']]`
`SELECT * FROM t WHERE c > 10`	`df[df['c'] > 10]` ([[Pandas Boolean Indexing]])
`ORDER BY c DESC`	`df.sort_values('c', ascending=False)`
`LIMIT 10`	`df.head(10)`
`DISTINCT c`	`df['c'].drop_duplicates()`
`WHERE c IN (...)`	`df[df['c'].isin([...])]`
`WHERE c LIKE '%x%'`	`df[df['c'].str.contains('x', na=False)]`
`CASE WHEN ...`	`np.where(...)`, `df['c'].map(...)`
`INSERT`	`pd.concat([df, new_rows])` 또는 `df.loc[len(df)] = ...`
`UPDATE ... SET c = ... WHERE ...`	`df.loc[mask, 'c'] = ...`
`DELETE ... WHERE ...`	`df = df[~mask]`
`WITH cte AS (...)`	중간 DataFrame 변수

UPDATE/DELETE 가 mask 한 줄로 처리되는 게 pandas 의 강점, 거꾸로 INSERT 의 효율은 SQL 이 압도적. 적재적소.

함정

1. SELECT * 를 운영 코드에

스키마 변경 시 깨짐
네트워크 비용
인덱스 only-scan 못 씀

명시적으로 컬럼 나열.

2. NULL 의 전파

SELECT col_a + col_b FROM t;   -- 어느 한쪽이 NULL 이면 결과 NULL
SELECT COALESCE(col_a, 0) + COALESCE(col_b, 0) FROM t;   -- 0 으로 대체

3. 묵시적 형변환

WHERE id = '1'    -- id 가 INTEGER 면 문자→숫자 변환, 인덱스 쓸 수 있음
WHERE CAST(id AS TEXT) = '1'   -- 컬럼에 함수 적용, 인덱스 깨짐

문자열 칼럼에 숫자를 넣으면 PG 는 에러, MySQL 은 묵시적 변환 (조용한 버그의 원천).

4. WHERE 와 HAVING 혼동

-- ❌ 에러: WHERE 는 집계 결과 못 봄
SELECT city, AVG(salary) FROM users WHERE AVG(salary) > 3000 GROUP BY city;

-- ✓ HAVING 에 써야 함
SELECT city, AVG(salary) FROM users GROUP BY city HAVING AVG(salary) > 3000;

자세한 GROUP BY 의 의미와 동작은 [[SQL GROUP BY]].

5. 페이지 깊은 OFFSET

운영 환경에서 무한 스크롤은 keyset pagination 으로.

[SQL] GROUP BY

koa (김신건) — Sat, 20 Jun 2026 00:00:00 GMT

정의

GROUP BY 는 데이터를 키별로 그룹으로 나누고 각 그룹에 집계 함수 (aggregate) 를 적용해 그룹당 한 행으로 줄이는 연산. SQL 의 split-apply-combine.

[[Pandas groupby]] 와 1:1 대응. 시각화도 동일하게 사용한다.

시각화

{}

기본 골격

SELECT 그룹키, 집계함수(컬럼)
FROM 테이블
[WHERE 조건]
GROUP BY 그룹키
[HAVING 그룹조건]
[ORDER BY ...]

실행 순서는 [[SQL]] 의 “쿼리 실행의 논리적 순서” 참고. WHERE → GROUP BY → HAVING → SELECT 임을 기억.

기본 예제

city 가 같은 행끼리 모이고 각 그룹에서 AVG(salary), COUNT(*) 가 계산된다.

집계 함수 (Aggregate Functions)

표준 SQL 의 핵심 집계.

함수	의미	NULL 처리
`COUNT(*)`	행 수 (NULL 포함)	NULL 행도 셈
`COUNT(col)`	non-NULL 행 수	NULL 제외
`COUNT(DISTINCT col)`	고유값 수	NULL 제외
`SUM(col)`, `AVG(col)`	합, 평균	NULL 무시
`MIN(col)`, `MAX(col)`	극값	NULL 무시
`STDDEV(col)`, `VARIANCE(col)`	표준편차, 분산	NULL 무시
`BOOL_AND`, `BOOL_OR` (PG)	모두 참, 하나라도 참	NULL 무시
`STRING_AGG(col, sep)` (PG) / `GROUP_CONCAT(col SEPARATOR sep)` (MySQL)	문자열 합	NULL 무시
`ARRAY_AGG(col)` (PG)	배열 합	NULL 포함
`JSON_AGG(col)` (PG) / `JSON_ARRAYAGG(col)` (MySQL 8+)	JSON 배열	dialect 따라

NULL 의 묵시적 무시 함정

-- score 컬럼에 NULL 이 섞여 있을 때
SELECT
  COUNT(*)        AS total,      -- NULL 포함
  COUNT(score)    AS scored,     -- NULL 제외
  AVG(score)      AS avg_score,  -- NULL 제외하고 평균
  SUM(score) / COUNT(*) AS my_avg  -- NULL 도 0 으로 친 평균 (보통 의도와 다름)
FROM exams;

[!IMPORTANT] AVG 는 분모가 non-NULL 개수. 결측치가 많을 때 의미가 변한다. 의도하면 COALESCE(score, 0) 으로 명시.

HAVING, 집계 조건

WHERE 는 집계 전, HAVING 은 집계 후.

<CodeWithOutput language=“sql” outputLanguage=“text” code={`— ❌ WHERE 에 집계 함수 (에러) SELECT city, COUNT() FROM users WHERE COUNT() > 2 GROUP BY city;

— ✓ HAVING 이 정답 SELECT city, COUNT() AS cnt FROM users GROUP BY city HAVING COUNT() > 2;} output={— 첫 번째: ERROR: aggregate functions are not allowed in WHERE

— 두 번째: city | cnt ---------+----- Seoul | 3`} />

-- WHERE + HAVING 같이 쓸 수도
SELECT city, AVG(salary)
FROM users
WHERE active = TRUE          -- 그룹 전, active 사용자만
GROUP BY city
HAVING AVG(salary) > 3000;    -- 그룹 후, 평균이 큰 city

여러 컬럼 그룹

SELECT city, dept, AVG(salary) AS avg_sal
FROM users
GROUP BY city, dept;

city	dept	avg_sal
Seoul	A	3250.0
Seoul	B	5000.0
Busan	A	4000.0
Busan	B	4500.0

(city, dept) 의 모든 고유 조합당 한 행.

ROLLUP / CUBE / GROUPING SETS

여러 수준의 소계/총계를 한 쿼리로.

SELECT city, dept, SUM(salary)
FROM users
GROUP BY ROLLUP (city, dept);

city	dept	sum
Seoul	A	6500
Seoul	B	5000
Seoul	NULL	11500 (city 소계)
Busan	A	4000
Busan	B	4500
Busan	NULL	8500
NULL	NULL	20000 (총계)

구문	의미
`ROLLUP (a, b)`	(a, b), (a), ()
`CUBE (a, b)`	(a, b), (a), (b), ()
`GROUPING SETS ((a, b), (a))`	사용자 정의

PG/MySQL 8 모두 지원. 분석/OLAP 보고서에 빠르고 깔끔.

GROUP BY 의 SELECT 제약

표준 SQL: SELECT 절에 나오는 비집계 컬럼은 모두 GROUP BY 에 있어야 한다.

-- ❌ 표준 위반: name 이 GROUP BY 에 없음
SELECT city, name, AVG(salary)
FROM users
GROUP BY city;

dialect 차이:

PostgreSQL: 엄격, 에러.
MySQL: 기본은 허용 (조용히 임의의 값). sql_mode=ONLY_FULL_GROUP_BY 면 엄격. MySQL 5.7+ 부터 ONLY_FULL_GROUP_BY 가 기본.

해법: 명시적 집계 또는 GROUP BY 에 포함.

SELECT city, MAX(name), AVG(salary) FROM users GROUP BY city;     -- 명시적 집계
SELECT city, name, AVG(salary)      FROM users GROUP BY city, name;  -- 그룹키 추가

DISTINCT vs GROUP BY

같은 결과지만 의미가 다르다.

SELECT DISTINCT city, dept FROM users;
SELECT city, dept           FROM users GROUP BY city, dept;

둘 다 같은 결과셋. 옵티마이저는 보통 같은 plan 으로 처리. GROUP BY 는 집계가 따라올 때, DISTINCT 는 단순 중복 제거 의도일 때.

윈도 함수 (Window Functions)

그룹별 집계를 행 단위로 보존하며 계산. GROUP BY 가 그룹당 한 행, 윈도는 모든 행 유지.

윈도 함수 종류

카테고리	함수	의미
집계	`SUM`, `AVG`, `COUNT`, …	`OVER` 가 있으면 윈도
순위	`ROW_NUMBER()`	1, 2, 3, … (동률 무시)
순위	`RANK()`	1, 2, 2, 4 (동률 공유, 다음 점프)
순위	`DENSE_RANK()`	1, 2, 2, 3 (동률 공유, 점프 없음)
순위	`NTILE(n)`	n 분위수
오프셋	`LAG(col, n)`, `LEAD(col, n)`	n 행 전/후 값
경계	`FIRST_VALUE`, `LAST_VALUE`, `NTH_VALUE`	윈도 내 위치 값
통계	`PERCENT_RANK`, `CUME_DIST`	누적 분포

윈도 프레임 (Frame)

OVER (PARTITION BY ... ORDER BY ... ROWS/RANGE BETWEEN ... AND ...).

-- 7 일 이동평균
SELECT
  date,
  amount,
  AVG(amount) OVER (
    ORDER BY date
    ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
  ) AS ma7
FROM daily_sales;

-- 누적합
SELECT
  date,
  amount,
  SUM(amount) OVER (ORDER BY date) AS cumsum
FROM daily_sales;

[[Pandas rolling]] / [[Pandas expanding]] 와 같은 개념.

pandas 와 GROUP BY

기본 대응

SQL	pandas
`GROUP BY city`	`df.groupby('city')`
`AVG(salary)`	`.mean()`
`COUNT(*)`	`.size()`
`COUNT(col)`	`.count()`
`COUNT(DISTINCT col)`	`.nunique()`
`SUM(col)`, `MIN(col)`, `MAX(col)`	`.sum()`, `.min()`, `.max()`
`HAVING ...`	`.filter(lambda g: ...)` 또는 `.agg(...).query(...)`
`GROUP BY a, b`	`df.groupby(['a', 'b'])`
`ROLLUP/CUBE`	`crosstab(margins=True)`, [[Pandas pivot_table]] `margins=True`
`ROW_NUMBER() OVER (PARTITION BY x ORDER BY y)`	`df.sort_values('y').groupby('x').cumcount() + 1`
`LAG(col)`	`df.groupby('x')['col'].shift(1)` ([[Pandas shift]])
`AVG(...) OVER (ROWS 6 PRECEDING)`	`df.rolling(7).mean()`

예시 비교

<CodeWithOutput variants={[ { language: ‘sql’, label: ‘SQL’, code: SELECT city, COUNT(*) AS cnt, AVG(salary) AS avg_sal, COUNT(DISTINCT dept) AS dept_cnt FROM users WHERE active = TRUE GROUP BY city HAVING COUNT(*) >= 2 ORDER BY avg_sal DESC; }, { language: ‘python’, label: ‘pandas’, code: result = ( df[df['active']] .groupby('city') .agg( cnt=('city', 'size'), avg_sal=('salary', 'mean'), dept_cnt=('dept', 'nunique'), ) .query('cnt >= 2') .sort_values('avg_sal', ascending=False) ) }, ]} outputLabel=“결과” output={-- 양쪽 모두 동일한 의미와 결과 -- city 별로 active 사용자만 집계, 2명 이상인 도시만, 평균 급여 내림차순} />

함정

1. WHERE 와 HAVING 헷갈림

-- WHERE 는 집계 전, HAVING 은 집계 후
WHERE  salary > 3000       -- 개별 행 필터
HAVING AVG(salary) > 3000  -- 그룹 필터

2. COUNT(*) vs COUNT(col)

-- 행 수
SELECT COUNT(*) FROM t;

-- non-NULL 행 수, 종종 의도와 다름
SELECT COUNT(active) FROM t;     -- active 가 NULL 인 행은 안 셈

3. COUNT 와 LEFT JOIN

-- 주문 없는 사용자 cnt 가 0 이 아니라 1 이 나오는 함정
SELECT u.name, COUNT(*) AS order_count
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
GROUP BY u.name;
-- COUNT(*) 는 LEFT JOIN 의 NULL 행도 셈 (1)

-- ✓ COUNT(o.id) 가 정답 (NULL 무시)
SELECT u.name, COUNT(o.id) AS order_count
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
GROUP BY u.name;

4. GROUP BY 후 정렬 컬럼

-- SELECT 의 별칭을 ORDER BY 에 쓸 수 있는지는 dialect 마다 다름
SELECT city, AVG(salary) AS avg_sal
FROM users GROUP BY city
ORDER BY avg_sal DESC;     -- PG/MySQL 모두 OK

5. 큰 카디널리티 GROUP BY

수억 행 × 그룹키가 수백만 → hash table 폭발. EXPLAIN ANALYZE 로 work_mem (PG) 또는 tmp_table_size (MySQL) 확인. [[External Merge Sort]] / Grace Hash 처럼 디스크 spill 발생.

[SQL] JOIN

koa (김신건) — Sat, 20 Jun 2026 00:00:00 GMT

정의

JOIN 은 두 개 이상의 테이블을 공통 컬럼 (보통 키) 으로 결합해 한 결과셋으로 만드는 연산. SQL 의 관계 모델 핵심.

종류는 5 가지: INNER, LEFT, RIGHT, FULL OUTER, CROSS. 같은 테이블끼리 결합하는 SELF JOIN 은 별도 종류가 아니라 같은 테이블을 두 번 참조하는 패턴.

pandas 의 [[Pandas merge]] 가 완전 대응되는 개념. 시각화는 동일하게 사용한다.

시각화

{}

4 가지 메인 JOIN 타입

how	SQL	결과
내부	`INNER JOIN`	양쪽 매칭만
좌측 외부	`LEFT [OUTER] JOIN`	왼쪽 전부 + 매칭, 없으면 NULL
우측 외부	`RIGHT [OUTER] JOIN`	오른쪽 전부 + 매칭
완전 외부	`FULL [OUTER] JOIN`	양쪽 합집합, 없으면 NULL
데카르트곱	`CROSS JOIN`	모든 조합 (m × n)

예제 데이터

INNER JOIN

양쪽 모두 매칭되는 행만.

Alice (2 주문), Bob (1 주문) 만. Charlie 는 주문 없음, orders.user_id=4 는 users 에 없음.

INNER 키워드는 생략 가능, JOIN 만 쓰면 INNER JOIN. 명시 권장.

LEFT JOIN

왼쪽 테이블의 모든 행 + 오른쪽 매칭. 없으면 오른쪽 컬럼은 NULL.

Charlie 도 나타난다, amount 는 NULL. “users 전부 + 그들의 주문” 같은 질문에 적합.

LEFT JOIN + IS NULL = 안티 조인

“오른쪽에 없는 왼쪽 행” 찾기.

NOT EXISTS / NOT IN 으로 같은 결과를 낼 수 있지만, 옵티마이저가 가장 효율적인 plan 을 짜기에 유리한 건 dialect/통계에 따라 다르다.

RIGHT JOIN

LEFT JOIN 의 좌우 반전.

SELECT u.id, u.name, o.amount
FROM users u
RIGHT JOIN orders o ON u.id = o.user_id;

id	name	amount
1	Alice	100
1	Alice	200
2	Bob	150
NULL	NULL	50

orders 의 user_id=4 행도 나타난다 (사용자 없음, NULL).

실무에선 RIGHT JOIN 보다 FROM 의 테이블 순서를 바꾸고 LEFT JOIN 쓰는 게 가독성 좋다.

FULL OUTER JOIN

양쪽 모두 보존, 매칭 안 되면 반대편이 NULL.

SELECT u.id, u.name, o.amount
FROM users u
FULL OUTER JOIN orders o ON u.id = o.user_id;

u.id	name	amount
1	Alice	100
1	Alice	200
2	Bob	150
3	Charlie	NULL
NULL	NULL	50

[!IMPORTANT] MySQL 은 FULL OUTER JOIN 을 직접 지원하지 않는다. LEFT JOIN UNION RIGHT JOIN 으로 흉내.

-- MySQL
SELECT u.id, u.name, o.amount
FROM users u LEFT JOIN orders o ON u.id = o.user_id
UNION
SELECT u.id, u.name, o.amount
FROM users u RIGHT JOIN orders o ON u.id = o.user_id;

CROSS JOIN

모든 조합 (데카르트곱). 행 수 = m × n.

SELECT u.name, c.color
FROM users u
CROSS JOIN colors c;

ON 절이 없다. 보통 의도된 사용은 작은 룩업 테이블 확장, 카탈로그 매트릭스 생성.

[!CAUTION] 큰 두 테이블 사이의 CROSS JOIN 은 즉시 메모리/디스크를 폭발시킨다. 1만 × 1만 = 1억 행.

암시적 cross join (구식):

SELECT u.name, c.color FROM users u, colors c;     -- 같은 결과

WHERE 절을 깜빡하면 의도치 않은 cross join 이 된다, 명시적 CROSS JOIN 이 안전.

SELF JOIN

같은 테이블을 두 번 참조. 보통 부모-자식 관계, 동일 도메인 비교.

-- 매니저-부하 관계
SELECT e.name AS employee, m.name AS manager
FROM employees e
LEFT JOIN employees m ON e.manager_id = m.id;

-- 같은 city 의 다른 사람
SELECT a.name, b.name AS roommate
FROM users a
JOIN users b
  ON a.city = b.city
 AND a.id   < b.id;     -- 중복 쌍 제거 (id 순으로만)

테이블 별칭이 필수.

ON vs USING vs NATURAL JOIN

ON

가장 일반적, 가장 명시적.

JOIN orders o ON u.id = o.user_id
JOIN orders o ON u.id = o.user_id AND o.status = 'active'

USING (양쪽 컬럼 이름 같을 때)

JOIN orders USING (user_id)
-- ON 절의 짧은 버전, 결과 컬럼이 한 번만 나옴

NATURAL JOIN

같은 이름의 모든 컬럼을 자동으로 매칭. 위험하다.

SELECT * FROM users NATURAL JOIN orders;
-- created_at, id 같은 우연히 겹친 컬럼까지 join 키가 됨

스키마가 바뀌면 의미가 조용히 바뀐다. 거의 항상 명시적 ON 권장.

여러 테이블 JOIN

SELECT u.name, o.id, p.name AS product
FROM users u
JOIN orders   o ON o.user_id    = u.id
JOIN order_items oi ON oi.order_id = o.id
JOIN products p  ON p.id         = oi.product_id
WHERE u.city = 'Seoul';

옵티마이저가 join 순서를 선택. 통계 가 정확하면 효율적, 아니면 nested-loop 폭발.

JOIN 알고리즘 (간단)

옵티마이저가 선택하는 물리 알고리즘 3 가지.

알고리즘	조건	비용
Nested Loop	한쪽이 작거나 인덱스 있는 경우	O(n × m), 인덱스 시 O(n log m)
Hash Join	등호 join, 한쪽이 메모리에 들어감	O(n + m), build/probe
Sort-Merge	양쪽 정렬됨 또는 정렬 비용 감당 가능	O(n log n + m log m)

대용량 hash join 은 [[External Merge Sort]] 와 비슷하게 메모리 부족 시 디스크로 spill 한다 (Grace Hash Join). PG/MySQL EXPLAIN ANALYZE 로 확인.

pandas 와 SQL JOIN

[[Pandas merge]] 와 1:1 대응.

SQL	pandas
`INNER JOIN`	`pd.merge(a, b, how='inner')`
`LEFT JOIN`	`pd.merge(a, b, how='left')`
`RIGHT JOIN`	`pd.merge(a, b, how='right')`
`FULL OUTER JOIN`	`pd.merge(a, b, how='outer')`
`CROSS JOIN`	`pd.merge(a, b, how='cross')`
`ON a.x = b.y`	`pd.merge(a, b, left_on='x', right_on='y')`
`USING (k)`	`pd.merge(a, b, on='k')`
`LEFT JOIN ... WHERE b.col IS NULL` (anti)	`df_a[~df_a['k'].isin(df_b['k'])]`
`JOIN ... ON range` (PG, 비등호)	`pd.merge_asof`, `IntervalIndex`

pandas 와 SQL 모두 동일한 set-theory 위에서 동작, 위 시각화는 pandas 와 공유한다.

함정

1. 다대다 폭증

users 와 orders 모두 같은 키가 중복돼 있으면 결과 행 수가 곱셈으로 증가.

-- users.id 가 1, 1
-- orders.user_id 가 1, 1, 1
-- → 2 × 3 = 6 행 (의도 아닐 수도)

GROUP BY 또는 서브쿼리로 한쪽 unique 화.

2. NULL 키리는 매칭 안 됨

ON u.col = o.col    -- 양쪽 NULL 이어도 매칭 X
ON u.col IS NOT DISTINCT FROM o.col     -- PostgreSQL, NULL=NULL 매칭

3. ON 과 WHERE 의 차이 (특히 OUTER JOIN)

-- LEFT JOIN 에서 ON 조건은 결합 단계, WHERE 는 결합 후
SELECT *
FROM users u
LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid';
-- Charlie 도 살아 있음 (왼쪽 보존)

SELECT *
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE o.status = 'paid';
-- Charlie 가 사라짐 (WHERE 가 NULL 행 제거, INNER JOIN 처럼 동작)

OUTER JOIN 에서 우측 컬럼 조건은 ON 에 두는 게 의도와 맞을 때가 많다.

4. SELECT * 의 컬럼 중복

SELECT * FROM users JOIN orders ON users.id = orders.user_id;
-- id 컬럼이 양쪽에서 나옴, 어떤 게 어떤 건지 모호

명시적으로 users.id, orders.id AS order_id.

MySQL

koa (김신건) — Sat, 20 Jun 2026 00:00:00 GMT

정의

MySQL 은 1995 년 MySQL AB (스웨덴) 가 만들어 2008 년 Sun → 2010 년 Oracle 로 인수된 오픈소스 RDBMS. GPL + 상용 듀얼 라이선스.

웹 백엔드의 사실상 표준 (LAMP/LEMP 스택). 단순함, 빠른 읽기, 풍부한 호스팅 옵션이 강점.

2010 년 Oracle 인수 직후 원 개발자 Monty Widenius 가 포크해 MariaDB 시작. 본 wiki 는 MySQL 8.0 기준, MariaDB 는 차이점만 언급.

표준 SQL 의 골격은 [[SQL]] 참고. 본 wiki 는 MySQL dialect-specific 한 부분만 정리.

핵심 특성

InnoDB 가 기본 스토리지 엔진 (5.5+): ACID, MVCC, 외래키 지원
MyISAM: 트랜잭션·외래키 없음, 가벼움. 거의 안 씀 (시스템 테이블 외)
격리 수준 기본 REPEATABLE READ: PG 와 다름. gap lock 으로 phantom 까지 방지
AUTO_INCREMENT: PK 자동 증가
단순한 복제: 비동기 master-replica (statement / row / mixed)
상대적으로 느슨한 표준 적합성: dialect 가 매우 강함

MySQL 만의 / 두드러진 문법

AUTO_INCREMENT

CREATE TABLE users (
  id   INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(50) NOT NULL,
  email VARCHAR(255) NOT NULL UNIQUE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

INSERT INTO users (name, email) VALUES ('Alice', 'a@x.com');
SELECT LAST_INSERT_ID();     -- 방금 INSERT 된 ID

-- 시작값 조정
ALTER TABLE users AUTO_INCREMENT = 1000;

AUTO_INCREMENT 는 INSERT 가 롤백돼도 소비. 빈 번호가 생긴다.

[[SQL DDL]] 의 자동 증가 PK 비교 참고.

ON DUPLICATE KEY UPDATE (UPSERT)

INSERT INTO users (email, name, login_count)
VALUES ('alice@x.com', 'Alice', 1)
ON DUPLICATE KEY UPDATE
  name        = VALUES(name),     -- 8.0.20 이하
  login_count = login_count + 1;

-- 8.0.20+ : alias 권장 (VALUES() 가 deprecated)
INSERT INTO users (email, name, login_count)
VALUES ('alice@x.com', 'Alice', 1) AS new_row
ON DUPLICATE KEY UPDATE
  name        = new_row.name,
  login_count = login_count + 1;

[!CAUTION] ON DUPLICATE KEY UPDATE 는 충돌 여부와 무관하게 AUTO_INCREMENT 카운터를 소비. 이를 피하려면 INSERT IGNORE + UPDATE 분리.

INSERT IGNORE / REPLACE

INSERT IGNORE INTO users (email, name) VALUES ('alice@x.com', 'Alice');
-- 충돌하면 조용히 무시 (다른 에러도 묵살, 위험)

REPLACE INTO users (email, name) VALUES ('alice@x.com', 'Alice');
-- 충돌하면 DELETE + INSERT, FK CASCADE 와 트리거가 함께 실행
-- → 외부 관계 끊김 가능, 권장 안 함

LIMIT + OFFSET

SELECT * FROM events ORDER BY id LIMIT 20 OFFSET 1000;
SELECT * FROM events ORDER BY id LIMIT 1000, 20;     -- 같은 의미 (offset, count)

PG/표준은 LIMIT n OFFSET m 또는 FETCH FIRST n ROWS ONLY.

LIMIT 가 있는 UPDATE / DELETE

UPDATE events SET archived = TRUE
WHERE created_at < '2024-01-01'
ORDER BY id
LIMIT 1000;

큰 테이블을 청크로 갱신할 때 매우 유용. PG 는 직접 지원하지 않고 CTE 우회.

GROUP_CONCAT

SELECT user_id, GROUP_CONCAT(tag ORDER BY tag SEPARATOR ',') AS tags
FROM user_tags
GROUP BY user_id;

PG 의 STRING_AGG(tag, ',') 에 대응. 기본 길이 제한 1024 (group_concat_max_len 으로 확장 가능).

JSON

PG 의 JSONB 만큼 강력하진 않지만 충분히 쓸 만하다.

CREATE TABLE events (id INT PK AUTO_INCREMENT, payload JSON);

INSERT INTO events (payload) VALUES
  ('{"user": 42, "tags": ["a","b"], "meta": {"ip": "1.2.3.4"}}');

-- 추출
SELECT payload -> '$.user',           -- 42 (JSON 값)
       payload ->> '$.user',          -- '42' (unquote, 문자)
       JSON_EXTRACT(payload, '$.meta.ip'),
       JSON_UNQUOTE(payload -> '$.meta.ip');

-- 포함
SELECT * FROM events
WHERE JSON_CONTAINS(payload, '42', '$.user');

-- 갱신
UPDATE events SET payload = JSON_SET(payload, '$.user', 99) WHERE id = 1;
UPDATE events SET payload = JSON_REMOVE(payload, '$.meta.ip') WHERE id = 1;

-- 인덱싱 (generated column 필요)
ALTER TABLE events
  ADD COLUMN user_id INT
    GENERATED ALWAYS AS (payload ->> '$.user') VIRTUAL,
  ADD INDEX idx_user_id (user_id);

-- 8.0+ : multi-valued index for JSON arrays
ALTER TABLE events ADD INDEX idx_tags ((CAST(payload -> '$.tags' AS CHAR(50) ARRAY)));

자세한 PG 와의 비교는 [[SQL Data Types]] 의 JSON 섹션 참고.

Full-text 인덱스

CREATE TABLE articles (
  id INT PRIMARY KEY,
  title VARCHAR(255),
  body  TEXT,
  FULLTEXT INDEX ft_body (title, body) WITH PARSER ngram     -- 한국어/중국어
) ENGINE=InnoDB;

SELECT *, MATCH(title, body) AGAINST('database' IN NATURAL LANGUAGE MODE) AS score
FROM articles
WHERE MATCH(title, body) AGAINST('database' IN NATURAL LANGUAGE MODE);

-- Boolean Mode
SELECT * FROM articles
WHERE MATCH(title, body) AGAINST('+database -mongodb' IN BOOLEAN MODE);

PG 는 tsvector + GIN 으로.

정규식

SELECT * FROM users WHERE name REGEXP '^A';
SELECT * FROM users WHERE name RLIKE '^A';     -- 동의어
SELECT REGEXP_REPLACE(name, '[0-9]', '');      -- 8+
SELECT REGEXP_LIKE(name, '^A.*');              -- 8+

대소문자 구분은 collation 에 따른다 (utf8mb4_general_ci 는 무시, utf8mb4_bin 은 구분).

사용자 변수와 흉내낸 윈도

8.0 이전엔 윈도 함수가 없어 사용자 변수로 흉내.

-- 5.7, ROW_NUMBER() 흉내
SELECT
  @rn := @rn + 1 AS rn,
  city,
  salary
FROM users, (SELECT @rn := 0) r
ORDER BY salary DESC;

-- 8.0+, 표준 윈도 함수 권장
SELECT ROW_NUMBER() OVER (ORDER BY salary DESC) AS rn, city, salary
FROM users;

8.0+ 에선 ROW_NUMBER, RANK, LAG, LEAD 등 표준 윈도 함수 전부 사용 가능.

CTE

8.0+ 부터 지원 (5.x 엔 없음).

WITH RECURSIVE org AS (
  SELECT id, manager_id, name, 1 AS depth
  FROM employees WHERE manager_id IS NULL
  UNION ALL
  SELECT e.id, e.manager_id, e.name, o.depth + 1
  FROM employees e JOIN org o ON e.manager_id = o.id
)
SELECT * FROM org;

LATERAL JOIN

8.0.14+ 부터 지원.

SELECT u.name, t.amount
FROM users u,
LATERAL (
  SELECT amount FROM orders
  WHERE user_id = u.id
  ORDER BY created_at DESC LIMIT 1
) AS t;

InnoDB 스토리지 엔진

특성	의미
ACID, MVCC	표준 트랜잭션
클러스터드 인덱스	PK 가 물리적 행 순서 (PG 는 heap)
보조 인덱스가 PK 참조	보조 인덱스 lookup 은 2 단계
FK 지원	MyISAM 은 미지원
행 단위 잠금	gap lock 으로 phantom 방지
자동 데드락 감지	한쪽 트랜잭션 롤백

[!IMPORTANT] InnoDB 의 클러스터드 인덱스 때문에 PK 선택이 매우 중요.

단조 증가 PK (AUTO_INCREMENT, ULID): 페이지 끝에 append, 빠름.

랜덤 PK (UUIDv4): 페이지 곳곳 쪼개기, 인덱스 fragmentation, 느려짐.

UUID 가 PK 라면 v7 / ULID 같은 시간 정렬 형을 권장. BINARY(16) 으로 저장 + UUID_TO_BIN(uuid, 1) (swap_flag=1) 로 시간 prefix 정렬.

sql_mode

MySQL 의 SQL 행동을 제어하는 세션/글로벌 변수.

SELECT @@sql_mode;
-- ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_DATE,...

SET sql_mode = 'STRICT_ALL_TABLES,NO_ZERO_DATE,ONLY_FULL_GROUP_BY';

모드	의미
`STRICT_TRANS_TABLES` / `STRICT_ALL_TABLES`	잘못된 값에 에러 (안 켜면 조용히 잘림/0)
`ONLY_FULL_GROUP_BY`	GROUP BY 표준 강제. [[SQL GROUP BY]] 참고.
`NO_ZERO_DATE`	’0000-00-00’ 금지
`NO_ENGINE_SUBSTITUTION`	없는 엔진 요청 시 에러
`ANSI`	표준 SQL 모드 (큰 비교: `
`TRADITIONAL`	엄격 모드 묶음

5.7+ 부터 strict + ONLY_FULL_GROUP_BY 가 기본. 5.6 이하 마이그레이션 시 데이터 정합성 이슈 다수 발견.

문자셋, collation

가장 흔한 함정 중 하나. 항상 utf8mb4.

CREATE DATABASE mydb DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
CREATE TABLE t (...) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

[!CAUTION] MySQL 의 utf8 은 3 바이트 utf8, 이모지 (4 바이트) 가 들어가면 에러. 항상 utf8mb4 를 써야 한다. MySQL 의 가장 악명 높은 함정.

collation	의미
`utf8mb4_0900_ai_ci`	8.0 기본, 악센트/대소문자 무시
`utf8mb4_unicode_ci`	5.7 흔함
`utf8mb4_bin`	바이트 단위 비교, 가장 엄격
`utf8mb4_general_ci`	빠르지만 부정확 (역사적), 권장 안 함

EXPLAIN

EXPLAIN SELECT * FROM users WHERE city = 'Seoul';
EXPLAIN FORMAT=JSON SELECT ...;
EXPLAIN ANALYZE SELECT ...;     -- 8.0.18+ (실제 실행 포함)

컬럼	의미
`type`	액세스 방법 (`const`, `eq_ref`, `ref`, `range`, `index`, `ALL`)
`key`	사용된 인덱스
`rows`	추정 검사 행 수
`Extra`	`Using index`, `Using filesort`, `Using temporary` 등

type=ALL 은 풀스캔, 큰 테이블에선 경고 신호.

트랜잭션과 잠금

기본 격리 REPEATABLE READ + gap lock. PG 와 다른 점:

InnoDB 의 REPEATABLE READ 는 표준의 SERIALIZABLE 에 가까움 (phantom 방지).
gap lock 으로 인해 의도치 않은 deadlock 이 발생할 수 있음.
운영 트래픽이 많으면 READ COMMITTED 로 낮추는 곳도 많다.

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;
SELECT ... FOR UPDATE;     -- 비관 잠금
SELECT ... FOR SHARE;       -- 공유 잠금
COMMIT;

자세한 트랜잭션 모델은 [[SQL DCL TCL]].

복제 (Replication)

방식	의미
Statement-based	실행한 SQL 을 replica 가 다시 실행 (부동소수, NOW() 등에 문제)
Row-based	변경된 행을 그대로 (안전, 8.0 기본)
Mixed	자동 선택

GTID (Global Transaction ID) 기반 복제가 8.0 표준. failover 가 단순해진다.

SHOW REPLICA STATUS;       -- 8.0.22+ (이전 SLAVE STATUS)

MariaDB 와의 차이

MariaDB 는 2010 년 포크된 이후 점점 다른 길. 주요 차이:

	MySQL 8.0	MariaDB 10.x/11.x
엔진	InnoDB	InnoDB, Aria, ColumnStore, …
JSON	네이티브 JSON	텍스트 alias (LONGTEXT + 함수)
윈도 함수	8.0+	10.2+
CTE	8.0+	10.2+
Sequences	없음 (AUTO_INCREMENT)	10.3+ SEQUENCE 지원
RETURNING	없음	10.5+ 일부 지원
Roles	8.0+	10.0+

라이선스 측면에선 MariaDB 가 BSL 등 점점 비표준 라이선스 도입. MySQL 도 Oracle 영향으로 신뢰 이슈가 있어, 양쪽 다 주의 깊게 봐야 한다.

MySQL vs PostgreSQL 요약

자세한 비교는 [[PostgreSQL]] 참고.

항목	MySQL	PostgreSQL
운영 단순성	매우 단순	보통 (autovacuum, 튜닝)
읽기 성능 (단순)	빠름	빠름
표준 적합성	보통	매우 높음
트랜잭션 DDL	부분	전체
복잡한 분석 쿼리	약함	강함 (CTE, 윈도, GIST)
JSON	JSON + generated col 트릭	JSONB (GIN 인덱스)
라이선스	GPL (Oracle)	PostgreSQL License

pandas 와 MySQL

from sqlalchemy import create_engine
engine = create_engine('mysql+pymysql://user:pwd@host:3306/db?charset=utf8mb4')

df = pd.read_sql("""
  SELECT id, JSON_EXTRACT(payload, '$.user') AS user_id, ts
  FROM events
  WHERE ts >= DATE_SUB(NOW(), INTERVAL 7 DAY)
""", engine)

df.to_sql('events_backup', engine, if_exists='append',
          index=False, chunksize=5000, method='multi')

[[Pandas read_sql]] 의 chunksize + method='multi' 패턴이 MySQL 대량 적재에 효과적. PG 의 COPY 같은 네이티브 bulk 가 없어서.

charset 미지정 시 latin1 로 해석돼 이모지/한글 깨짐. ?charset=utf8mb4 필수.

함정

1. utf8 vs utf8mb4

이미 위에서. 항상 utf8mb4.

2. 묵시적 형변환

SELECT '1' + 1;     -- 2
SELECT 'a' + 1;     -- 1 (조용히 'a' → 0)
SELECT 1 = '1abc';  -- TRUE (1 = 1)

PG 는 에러, MySQL 은 조용한 버그. STRICT 모드 + 명시적 CAST 권장.

3. AUTO_INCREMENT 의 갭

INSERT ... (id 5 할당)
ROLLBACK;                    -- 5 는 안 돌아옴
INSERT ... (id 6 할당)

ID 가 연속이라고 가정하는 코드는 깨진다.

4. DATETIME vs TIMESTAMP

DATETIME: timezone 없음, 그대로 저장 (1000-9999)
TIMESTAMP: 세션 timezone 으로 해석 → UTC 저장 → 다시 변환 (1970-2038)

TIMESTAMP 의 32-bit Unix time 제한 때문에 2038 년 문제. 큰 시간 범위 필요하면 DATETIME + 애플리케이션 timezone 관리.

5. ENUM 의 정렬

ENUM('low', 'medium', 'high')
ORDER BY priority;     -- 정의 순으로 정렬 (low < medium < high)

문자열 알파벳 순이 아닌, 정의 순서가 정렬 키. 의도일 수도, 사고일 수도.

6. NULL 의 UNIQUE

-- MySQL InnoDB
CREATE TABLE t (email VARCHAR(255) UNIQUE);
INSERT INTO t VALUES (NULL), (NULL), (NULL);     -- 모두 허용!
-- UNIQUE 는 NULL 끼리 중복으로 안 봄 (표준)

PG 도 동일. 표준 정의. 의도와 다르면 NOT NULL 추가.

7. ON DELETE 의 묵시적 동작

InnoDB 의 FK 가 ON DELETE 옵션 없이 만들어지면 기본은 RESTRICT (참조 있으면 부모 삭제 거부). 명시적으로 적는 게 안전.

PostgreSQL

koa (김신건) — Sat, 20 Jun 2026 00:00:00 GMT

정의

PostgreSQL 은 1986 년 UC Berkeley 의 POSTGRES 프로젝트에서 출발해 1996 년 SQL 지원 버전으로 오픈소스화된 객체-관계형 DBMS (ORDBMS). PostgreSQL Global Development Group 이 관리, PostgreSQL License (BSD/MIT 계열).

표준 SQL 적합성, 확장성 (extension), 강력한 JSONB, 풍부한 인덱스 종류, 표준 호환 MVCC 가 특징. “오픈소스의 Oracle”.

표준 SQL 의 골격은 [[SQL]] 참고. 본 wiki 는 PostgreSQL dialect-specific 한 부분만 정리.

핵심 특성

표준 적합성 높음: SQL:2023 의 상당 부분 구현.
MVCC: 읽기-쓰기 비차단. 자세한 격리 수준은 [[SQL DCL TCL]] 참고.
확장성: CREATE EXTENSION 으로 PostGIS, pg_trgm, hstore, vector (pgvector) 등.
JSONB: 바이너리 JSON, 인덱싱 + containment 강력.
배열 / 범위 / 사용자 정의 타입: 표준을 넘어선 풍부함.
다양한 인덱스: B-tree, Hash, GIN, GiST, BRIN, SP-GiST.
트랜잭션 DDL: CREATE TABLE 도 롤백 가능. 마이그레이션 안정성에 결정적.

PostgreSQL 만의 / 두드러진 문법

SERIAL 과 IDENTITY

[[SQL DDL]] 의 자동 증가 PK 비교 참고. 짧게:

-- 구식 (여전히 흔함)
CREATE TABLE t (id SERIAL PRIMARY KEY);

-- 표준 (10+ 권장)
CREATE TABLE t (id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY);
CREATE TABLE t (id INTEGER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY);

SERIAL 은 실제로 시퀀스 + DEFAULT 의 sugar. 권한 관리, 백업/복원 시 약점이 있어 IDENTITY 가 더 깔끔.

RETURNING

INSERT/UPDATE/DELETE 의 결과를 즉시 반환. MySQL 에는 없는 강력한 기능.

<CodeWithOutput language=“sql” outputLanguage=“text” code={`INSERT INTO users (name, city) VALUES (‘Alice’, ‘Seoul’) RETURNING id, created_at;

UPDATE accounts SET balance = balance - 100 WHERE id = 1 AND balance >= 100 RETURNING balance;

DELETE FROM events WHERE created_at < NOW() - INTERVAL ‘30 day’ RETURNING id;} output={ id | created_at ----+------------------------ 4 | 2026-06-20 14:23:01+09

balance

— 삭제된 행들의 id 가 반환됨`} />

CTE 와 결합하면 한 쿼리로 복잡한 워크플로 처리.

WITH moved AS (
  DELETE FROM staging WHERE processed_at IS NOT NULL
  RETURNING *
)
INSERT INTO archive SELECT * FROM moved;

ON CONFLICT (UPSERT)

INSERT INTO users (email, name, login_count)
VALUES ('alice@x.com', 'Alice', 1)
ON CONFLICT (email) DO UPDATE
SET name        = EXCLUDED.name,
    login_count = users.login_count + 1
RETURNING id, login_count;

-- 무시
INSERT INTO users (email, name) VALUES ('alice@x.com', 'Alice')
ON CONFLICT DO NOTHING;

-- 조건부 update
ON CONFLICT (email) DO UPDATE SET ... WHERE users.login_count < 100;

race-condition 측면에서 가장 안전한 upsert. 동일 키에 충돌 시 atomic.

JSONB

CREATE TABLE events (id SERIAL PK, payload JSONB);

-- 인덱스
CREATE INDEX idx_events_payload ON events USING GIN (payload);
CREATE INDEX idx_events_user ON events ((payload ->> 'user'));

-- 연산자
payload -> 'key'         -- jsonb
payload ->> 'key'        -- text
payload #> '{a,b,c}'     -- 깊은 경로 (jsonb)
payload #>> '{a,b,c}'    -- 깊은 경로 (text)
payload @> '{"x":1}'     -- containment, GIN 인덱스 가능
payload ? 'key'          -- key 존재
payload ?| array['a','b']  -- 어느 key 라도 존재
payload || other_jsonb   -- 병합

-- 갱신 (15+)
UPDATE events SET payload = jsonb_set(payload, '{user}', '99'::jsonb);

자세한 비교는 [[SQL Data Types]] 의 JSON 섹션 참고.

배열

CREATE TABLE posts (id SERIAL PK, tags TEXT[]);

SELECT * FROM posts WHERE tags @> ARRAY['db'];      -- 포함
SELECT * FROM posts WHERE 'sql' = ANY(tags);
SELECT id, t FROM posts, unnest(tags) AS t;          -- 펼침
SELECT array_agg(name ORDER BY name) FROM users;     -- 집계

정규식

SELECT * FROM users WHERE name ~ '^A';          -- 대소문자 구분
SELECT * FROM users WHERE name ~* '^a';         -- 대소문자 무시
SELECT REGEXP_REPLACE(name, '[^a-zA-Z]', '', 'g');
SELECT REGEXP_MATCHES('foo123bar456', '[0-9]+', 'g');
-- → {'123'}, {'456'} 두 행

PostgreSQL 의 정규식은 POSIX 확장 + 일부 Perl 호환.

윈도 함수와 PARTITION BY

표준이지만 PG 가 가장 풍부한 옵션을 가진다.

SELECT
  city,
  salary,
  RANK()         OVER w AS rnk,
  PERCENT_RANK() OVER w AS pct,
  AVG(salary)    OVER (PARTITION BY city
                       ORDER BY hired_at
                       ROWS BETWEEN 5 PRECEDING AND CURRENT ROW) AS ma
FROM users
WINDOW w AS (PARTITION BY city ORDER BY salary DESC);

WINDOW 절로 윈도 정의를 이름 붙여 재사용. [[SQL GROUP BY]] 의 윈도 섹션 참고.

CTE 와 재귀

WITH RECURSIVE org AS (
  SELECT id, manager_id, name, 1 AS depth
  FROM employees WHERE manager_id IS NULL
  UNION ALL
  SELECT e.id, e.manager_id, e.name, o.depth + 1
  FROM employees e JOIN org o ON e.manager_id = o.id
)
SELECT * FROM org ORDER BY depth, name;

PG 12+ 부터 CTE 가 기본 inline. 이전엔 항상 materialize 라 옵티마이저 fence 로 활용했다 (현재는 MATERIALIZED / NOT MATERIALIZED 명시).

LATERAL JOIN

오른쪽 서브쿼리가 왼쪽의 컬럼을 참조 가능. “각 행마다 별도 쿼리”.

SELECT u.name, recent.amount, recent.created_at
FROM users u
LEFT JOIN LATERAL (
  SELECT amount, created_at
  FROM orders
  WHERE user_id = u.id
  ORDER BY created_at DESC
  LIMIT 3
) recent ON TRUE;

각 사용자의 최근 3 주문. MySQL 도 8.0.14+ 지원하지만 PG 가 먼저.

DISTINCT ON

표준이 아니지만 매우 유용. “그룹별 첫 행” 을 짧게.

SELECT DISTINCT ON (user_id) user_id, created_at, amount
FROM orders
ORDER BY user_id, created_at DESC;
-- 각 user 의 가장 최근 주문 한 건

같은 결과를 윈도 함수로:

SELECT user_id, created_at, amount
FROM (
  SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) rn
  FROM orders
) t WHERE rn = 1;

MVCC 와 VACUUM

PG 의 MVCC 는 UPDATE/DELETE 시 이전 버전을 삭제하지 않고 dead tuple 로 남긴다. 트랜잭션이 끝나도 다른 트랜잭션이 볼 수 있어서 즉시 제거 불가.

도구	역할
`VACUUM`	dead tuple 회수 (공간 재사용)
`VACUUM FULL`	테이블 재작성 (락 잡음, 운영 X)
`ANALYZE`	통계 갱신 (옵티마이저 입력)
`autovacuum`	백그라운드 자동 실행

dead tuple 누적 → 테이블 bloat → 쿼리 느려짐. autovacuum 튜닝이 운영 핵심 과제.

SELECT relname, n_dead_tup, n_live_tup,
       round(n_dead_tup::numeric / NULLIF(n_live_tup, 0) * 100, 2) AS dead_pct
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC LIMIT 10;

인덱스 종류

표준에 없는 다양한 인덱스. [[SQL DDL]] 의 인덱스 섹션 참고.

종류	용도
B-tree	등호, 범위, ORDER BY (기본)
Hash	등호만 (B-tree 와 차이 미미)
GIN	JSONB, 배열, tsvector (풀텍스트)
GiST	공간, 범위, 트라이그램
BRIN	거대 테이블 + 물리적 클러스터링 (시계열)
SP-GiST	비균형 트리 (전화번호 prefix 등)

-- JSONB 부분 인덱스
CREATE INDEX idx_active_users
  ON users USING GIN ((payload -> 'tags'))
  WHERE active = TRUE;

-- BRIN, 수억 행 시계열에 효과적
CREATE INDEX idx_events_ts_brin ON events USING BRIN (ts);

EXPLAIN

쿼리 plan 확인.

EXPLAIN SELECT * FROM users WHERE city = 'Seoul';
EXPLAIN ANALYZE SELECT ...;        -- 실제 실행 (주의: UPDATE/DELETE 도 실행됨)
EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) SELECT ...;

BEGIN;
EXPLAIN ANALYZE UPDATE ...;     -- 변경 후
ROLLBACK;                        -- 되돌림 (PG 의 트랜잭션 DDL/DML 덕분)

확장 (Extensions)

CREATE EXTENSION 으로 기능 추가.

확장	용도
`pg_trgm`	트라이그램, LIKE ‘%xx%’ 인덱스
`postgis`	공간 데이터
`pgvector`	벡터 검색 (임베딩)
`hstore`	key-value (JSONB 등장 전 흔히 썼음)
`pg_stat_statements`	쿼리 통계
`pgcrypto`	해시, AES
`uuid-ossp`	UUID 생성기
`pg_partman`	파티션 자동화
`citus`	분산 PG

파티셔닝

PG 10+ 부터 선언적 파티셔닝.

CREATE TABLE events (
  id BIGSERIAL,
  ts TIMESTAMPTZ NOT NULL,
  payload JSONB
) PARTITION BY RANGE (ts);

CREATE TABLE events_2026q1 PARTITION OF events
  FOR VALUES FROM ('2026-01-01') TO ('2026-04-01');

CREATE TABLE events_2026q2 PARTITION OF events
  FOR VALUES FROM ('2026-04-01') TO ('2026-07-01');

조건: 파티션 키가 쿼리에 자주 등장해야 partition pruning 이 작동.

복제 / HA

방식	의미
Streaming Replication	WAL 을 replica 에 실시간 전송
Logical Replication	publication/subscription 단위, 다른 버전 간 가능
Patroni / repmgr	자동 failover
Foreign Data Wrapper (FDW)	다른 DB 를 외부 테이블로

PostgreSQL vs MySQL 요약

자세한 비교는 [[MySQL]] 참고.

항목	PostgreSQL	MySQL
표준 적합성	매우 높음	보통 (개선 중)
기본 격리 수준	READ COMMITTED	REPEATABLE READ (InnoDB)
JSON	JSONB (인덱싱)	JSON (generated column 트릭)
배열 타입	✓	✗
FULL OUTER JOIN	✓	✗ (UNION 우회)
RETURNING	✓	✗ (MariaDB 만)
트랜잭션 DDL	✓	8.0 부분
라이선스	PostgreSQL License (BSD 계열)	GPL (오라클 소유)
풀텍스트	tsvector + GIN	FULLTEXT 인덱스

pandas 와 PostgreSQL

from sqlalchemy import create_engine
engine = create_engine('postgresql+psycopg2://user:pwd@host:5432/db')

df = pd.read_sql("""
  SELECT id, payload ->> 'user' AS user_id, ts
  FROM events
  WHERE ts >= NOW() - INTERVAL '7 day'
""", engine)

대량 적재는 COPY 가 가장 빠르다. [[Pandas read_sql]] 의 psql_insert_copy 예제 참고.

JSONB 컬럼을 pandas 로 읽으면 dict (object dtype). 자주 쓰는 키는 SQL 단계에서 평탄화 후 가져오는 게 더 효율적.

함정

1. SERIAL 의 시퀀스 권한

GRANT INSERT ON t TO alice;
-- 그래도 INSERT 실패: 시퀀스 USAGE 권한 필요
GRANT USAGE ON SEQUENCE t_id_seq TO alice;

IDENTITY 는 이 문제가 없다.

2. 대소문자 식별자

CREATE TABLE "MyTable" (...);     -- 따옴표 → 대소문자 보존
SELECT * FROM MyTable;            -- 실패 (mytable 로 변환)
SELECT * FROM "MyTable";          -- 성공

따옴표는 피하고 snake_case 권장.

3. NULL 의 GROUP BY

-- PG 는 NULL 그룹을 모음 (MySQL 도 동일)
SELECT city, COUNT(*) FROM users GROUP BY city;

4. 시간대 (TIMESTAMPTZ)

[[SQL Data Types]] 의 날짜·시간 섹션 참고. 운영은 항상 TIMESTAMPTZ.

5. autovacuum 끄기

성능 이슈가 있어도 절대 끄지 말 것. 튜닝으로 해결 (autovacuum_vacuum_scale_factor, _threshold).

6. CTE 의 최적화 변화

PG 11 이하: CTE 는 항상 머티리얼라이즈 (옵티마이저 fence). PG 12+: 기본 inline. 강제하려면 WITH ... AS MATERIALIZED ....

SQL

koa (김신건) — Sat, 20 Jun 2026 00:00:00 GMT

정의

SQL (Structured Query Language) 은 관계형 데이터베이스 (RDBMS) 와 대화하기 위한 선언형 (declarative) 질의 언어. 1970 년 E.F. Codd 의 관계 모델 논문에서 출발, 1986 년 ANSI 표준화 (SQL-86), 이후 SQL:2023 까지 개정.

“무엇을 (what)” 만 적고 “어떻게 (how)” 는 옵티마이저가 결정한다. 같은 결과를 만드는 실행 경로는 수천 가지일 수 있고, RDBMS 가 통계 기반으로 가장 빠른 길을 고른다.

4 개의 하위 언어

표준 SQL 은 목적에 따라 4 개 카테고리로 나뉜다.

카테고리	풀네임	키워드	용도
DDL	Data Definition Language	`CREATE`, `ALTER`, `DROP`, `TRUNCATE`	스키마 정의
DML	Data Manipulation Language	`SELECT`, `INSERT`, `UPDATE`, `DELETE`	데이터 조작
DCL	Data Control Language	`GRANT`, `REVOKE`	권한 제어
TCL	Transaction Control Language	`BEGIN`, `COMMIT`, `ROLLBACK`, `SAVEPOINT`	트랜잭션 제어

각 항목은 별도 wiki 로 깊이 다룬다, [[SQL DDL]] / [[SQL DML]] / [[SQL DCL TCL]].

일부 문헌은 SELECT 를 DQL (Data Query Language) 로 분리하기도 한다. ISO 표준은 DML 에 포함시킨다.

빠르게 보기

쿼리 실행의 논리적 순서

작성 순서와 실행 순서는 다르다. SELECT 를 먼저 쓰지만, 옵티마이저는 FROM 부터 평가한다.

{}

순서	절	의미
1	`FROM` / `JOIN`	소스 테이블 결합
2	`WHERE`	행 필터 (그룹화 전)
3	`GROUP BY`	그룹 분할
4	`HAVING`	그룹 필터
5	`SELECT`	컬럼 선택, 표현식 평가
6	`DISTINCT`	중복 제거
7	`ORDER BY`	정렬
8	`LIMIT` / `OFFSET`	페이징

[!IMPORTANT] WHERE 는 집계 결과를 참조할 수 없다 (SELECT 보다 먼저 실행되니까). 집계 조건은 HAVING 에 쓴다.

pandas 와의 1:1 대응

[[Pandas]] 의 DataFrame 연산은 SQL 과 거의 대칭이다. 같은 개념의 두 표현.

SQL	pandas	비고
`SELECT col1, col2 FROM t`	`df[['col1', 'col2']]`	컬럼 선택
`WHERE col > 10`	`df[df['col'] > 10]`	[[Pandas Boolean Indexing]]
`ORDER BY col DESC`	`df.sort_values('col', ascending=False)`	정렬
`LIMIT 10`	`df.head(10)`	상위 N
`DISTINCT col`	`df['col'].unique()` / `drop_duplicates`	중복 제거
`GROUP BY` + `AVG(x)`	`df.groupby(...).mean()`	[[Pandas groupby]]
`INNER JOIN`	`pd.merge(a, b, how='inner')`	[[Pandas merge]]
`LEFT JOIN`	`pd.merge(a, b, how='left')`	[[Pandas merge]]
`UNION ALL`	`pd.concat([a, b])`	[[Pandas concat]]
`CASE WHEN`	`np.where` / `pd.cut`	조건 분기
윈도 `ROW_NUMBER()`	`df.groupby(...).cumcount()`	그룹 내 순번
`INSERT INTO`	`df.to_sql(...)`	[[Pandas read_sql]]

DB 와 직접 주고받는 통로는 [[Pandas read_sql]] 참고.

표준 SQL vs dialect

ANSI/ISO 표준은 골격, 실제 구현은 dialect 마다 차이가 크다.

영역	표준 (SQL:2023)	PostgreSQL	MySQL
자동 증가 PK	`IDENTITY`	`SERIAL`, `GENERATED ... AS IDENTITY`	`AUTO_INCREMENT`
문자열 결합	`		`
상위 N	`FETCH FIRST n ROWS ONLY`	`LIMIT n` (+ `FETCH`)	`LIMIT n`
Upsert	`MERGE`	`INSERT ... ON CONFLICT`	`INSERT ... ON DUPLICATE KEY UPDATE`
부울	`BOOLEAN`	`BOOLEAN` (네이티브)	`BOOLEAN` ≡ `TINYINT(1)`
JSON	`JSON`	`JSON`, `JSONB` (인덱싱 가능)	`JSON` (인덱싱은 generated column)
정규식	`LIKE_REGEX` (거의 미구현)	`~`, `~`, `regexp_`	`REGEXP`, `RLIKE`

상세는 [[PostgreSQL]], [[MySQL]] 참고.

데이터 타입 그룹

연산은 타입에 따라 가능 여부와 결과가 달라진다.

그룹	예	주요 연산
숫자	`INTEGER`, `BIGINT`, `NUMERIC`, `DOUBLE`	산술, 집계, `ROUND/CEIL/FLOOR`
문자열	`VARCHAR`, `TEXT`, `CHAR`	`LIKE`, 정규식, `CONCAT`, `SUBSTRING`
날짜/시간	`DATE`, `TIMESTAMP`, `TIMESTAMPTZ`, `INTERVAL`	차이, 추출, 트런케이션, `INTERVAL` 산술
부울	`BOOLEAN`	`AND`, `OR`, `NOT`
이진	`BYTEA` (PG), `BLOB` (MySQL)	길이, 해시, 인코딩
JSON	`JSON`, `JSONB` (PG)	경로 추출, containment, 인덱스
배열 (PG)	`INTEGER[]`, `TEXT[]`	`ANY/ALL`, 슬라이싱, `unnest`
공간	`GEOMETRY`, `GEOGRAPHY` (PostGIS)	거리, 포함, 교차

타입별 연산은 [[SQL Data Types]] 에서 자세히.

NULL 의 3-값 논리

SQL 의 가장 까다로운 부분.

SELECT NULL = NULL;        -- NULL (FALSE 가 아님)
SELECT NULL <> NULL;       -- NULL
SELECT NULL IS NULL;       -- TRUE
SELECT 1 + NULL;           -- NULL
SELECT COUNT(*) FROM t;    -- NULL 포함
SELECT COUNT(col) FROM t;  -- NULL 제외

비교 결과가 TRUE / FALSE / NULL 3 가지
WHERE 절은 TRUE 인 행만 통과 (NULL 도 제외)
집계 함수는 NULL 을 자동 무시 (단 COUNT(*) 는 행 자체를 셈)
NULL 비교는 IS NULL / IS NOT NULL / IS DISTINCT FROM

학습 경로

스키마: [[SQL DDL]]
데이터 조작: [[SQL DML]]
결합: [[SQL JOIN]]
집계: [[SQL GROUP BY]]
권한·트랜잭션: [[SQL DCL TCL]]
타입별 연산: [[SQL Data Types]]
dialect: [[PostgreSQL]], [[MySQL]]

Redis

koa (김신건) — Mon, 15 Jun 2026 00:00:00 GMT

정의

Redis (REmote DIctionary Server)는 인메모리 키-값 저장소이다. Salvatore Sanfilippo가 2009년 만들었고, 현재는 Redis Ltd. 가 개발을 주도한다. BSD 라이선스 (7.4부터는 RSALv2/SSPLv1 듀얼).

메모리에 데이터를 올려 microsecond 단위 응답 속도를 제공한다. 캐시, 세션 저장소, 메시지 브로커, 리더보드 등에 쓰인다.

핵심 특성

Single-threaded event loop: 명령 처리는 단일 스레드, I/O multiplexing (epoll/kqueue)으로 동시 처리
영속성 옵션: RDB snapshot 또는 AOF (append-only file) 로 디스크 백업 가능
복제(Replication): master-replica 구조, 비동기 복제
Pub/Sub: [[pubsub-bus]] 메시지 브로커 기능
트랜잭션: MULTI/EXEC로 명령 묶기, ACID는 아님 (격리 수준 낮음)

데이터 타입

타입	설명	주요 사용처
String	바이너리 안전 문자열, 최대 512MB	캐시, counter (INCR/DECR)
List	연결 리스트, 양끝 삽입/삭제 O(1)	큐, 최근 항목 목록
Hash	field-value 맵	객체 저장 (user:1 → {name, email})
Set	중복 없는 문자열 집합	태그, 멤버십, 집합 연산
Sorted Set	스코어로 정렬된 집합	리더보드, 타임라인
Stream	append-only 로그, consumer group	이벤트 소싱, 메시지 큐
HyperLogLog	확률적 카디널리티 추정	unique visitor 카운팅 (메모리 절약)
Geo	경도/위도 좌표, 반경 검색	위치 기반 서비스
Bitmap	비트 배열 (String 기반)	출석 체크, feature flag

영속성 (Persistence)

방식	동작	장점	단점
RDB	주기적 snapshot (SAVE/BGSAVE)	파일 작음, 복구 빠름	마지막 snapshot 이후 데이터 손실 가능
AOF	모든 쓰기 명령 로그	손실 최소화 (fsync 정책 따라)	파일 큼, 복구 느림 (REWRITE 필요)

혼용 가능 (RDB + AOF). fsync 정책: always (느리지만 안전) / everysec (기본, 최대 1초 손실) / no (OS 관리).

복제·고가용성

Master-Replica: 비동기 복제, replica는 읽기 전용
Sentinel: 자동 failover, 모니터링, 알림
Cluster: 수평 확장, 16384 슬롯 hash partitioning, 노드 장애 시 자동 failover

Cluster는 단일 명령이 여러 슬롯에 걸치면 실행 불가 (hash tag {user:1} 로 회피 가능).

캐싱 패턴

{}

{}

패턴	설명	장단점
Cache-aside (Look-aside)	앱이 읽기 전 캐시 확인 → miss면 DB 읽고 캐시 갱신	가장 흔함, 캐시/DB 불일치 가능
Write-through	쓰기마다 캐시+DB 동시 갱신	일관성 높음, 쓰기 느림
Write-behind (Write-back)	캐시 먼저 쓰고 비동기로 DB 반영	쓰기 빠름, 장애 시 손실 위험

TTL (Time-To-Live) + Eviction policy (메모리 부족 시):

noeviction: 쓰기 거부
allkeys-lru, allkeys-lfu: 전체 키 중 LRU/LFU 제거
volatile-lru, volatile-lfu: TTL 있는 키만 대상
allkeys-random, volatile-random: 무작위 제거

주요 사용처

캐시: DB 쿼리 결과, API 응답, 세션 데이터
Session Store: 분산 환경에서 사용자 세션 공유
Rate Limiting: INCR + EXPIRE로 요청 수 제한
Leaderboard: Sorted Set으로 랭킹 실시간 갱신
Pub/Sub Bus: 실시간 알림, 채팅 메시지 브로커
Queue: List (LPUSH/RPOP) 또는 Stream + consumer group
분산 락: SETNX + EXPIRE (Redlock 알고리즘)

약점·주의점

메모리 비용: 모든 데이터가 RAM에, 큰 데이터셋은 비쌈
Single-thread 제약: 무거운 연산 (KEYS *, SMEMBERS 큰 Set) 은 전체 차단
Key 단위 Atomicity: 여러 키 걸친 트랜잭션은 롤백 불가 (MULTI/EXEC는 isolation 약함)
데이터 일관성: 비동기 복제라 failover 시 일부 쓰기 손실 가능
네트워크 비용: 클라이언트-서버 왕복, 파이프라이닝으로 완화

김신건의 로그 - 위키 / sql

[SQL] Data Types

정의

타입 분류

숫자 타입

NUMERIC vs DOUBLE

자주 쓰는 연산

문자열 타입

자주 쓰는 연산

LIKE vs ILIKE vs 정규식

부울

날짜·시간

MySQL 의 TIMESTAMP

PostgreSQL 의 TIMESTAMPTZ

현재 시각

산술

시간대 함정

JSON

배열 (PostgreSQL)

UUID

ENUM

타입 변환 (CAST)

pandas 와 타입 대응

함정

1. VARCHAR(N) 의 N

2. TIMESTAMP vs TIMESTAMPTZ

3. NUMERIC 의 정밀도

4. FLOAT 의 비교

5. NULL 의 정렬

6. 묵시적 변환 (MySQL)

관련 위키

[SQL] DCL TCL

정의

트랜잭션과 ACID

BEGIN / COMMIT / ROLLBACK

autocommit 의 함정

SAVEPOINT

격리 수준 (Isolation Level)

dialect 기본값

MVCC, 잠금, 비교

데드락

DCL: GRANT / REVOKE

사용자/역할

권한 부여

컬럼 단위 권한

REVOKE

권한 확인

RLS (Row Level Security, PostgreSQL)

트랜잭션과 DDL

2-Phase Commit (분산 트랜잭션)

pandas 와 트랜잭션

함정

1. 트랜잭션 너무 길게

2. SELECT 결과의 즉시성

3. 데드락은 정상

4. 권한 누락

5. GRANT OPTION 의 전파

6. 최소 권한 원칙

관련 위키

[SQL] DDL

정의

핵심 키워드

CREATE TABLE 기본

제약조건 (Constraints)

복합 키 / 외래 키

명명된 제약

자동 증가 PK, dialect 차이

ALTER TABLE

컬럼 추가/삭제/수정

제약조건 추가/제거

테이블 이름 변경

큰 테이블에서 주의

DROP TABLE

TRUNCATE

CREATE INDEX

인덱스가 효과 없는 경우

CREATE VIEW

머티리얼라이즈드 뷰 (Materialized View)

CREATE SCHEMA

SEQUENCE (PostgreSQL)