SELECT * 가 anti-pattern

~10 min · operations, queries

Level 0스키마 새싹

0 XP0/86 lessons0/10 achievements

0/120 XP to next level120 XP to go0% complete

프로덕션 코드가 SELECT * 쓰면 안 되는 이유

SELECT * 가 psql 탐색엔 OK. 프로덕션 코드선 시한폭탄:

네트워크로 모든 컬럼 — 낭비된 대역폭.
Covering 인덱스 무력화 — planner 가 모든 컬럼 fetch 해야 하면 index-only scan 못 고름.
컬럼 추가 또는 재배치 시 미묘하게 깨짐 — 세 번째 컬럼이 X 라고 가정한 코드가 이제 Y read.
의도 흐림 — reader 가 쿼리가 어느 필드 의존하는지 모름.

룰

프로덕션 코드는 명시 컬럼 나열. 마이그레이션과 일회성 스크립트는 SELECT * OK. Default 로 모든 컬럼 선택하는 ORM 이 가끔 받아들일 만함 (매핑이 type-checked) — 그러나 테이블에 한 달에 한 번 read 하는 4MB JSONB 컬럼 있으면 그게 이제 모든 fetch 에.

Code

나쁨과 좋음·sql

-- 나쁨
SELECT * FROM users WHERE id = ?;

-- 좋음
SELECT id, name, email, role FROM users WHERE id = ?;

ORM 과 SELECT * 함정·python

# SQLAlchemy: default 로 모든 컬럼 fetch
users = session.query(User).all()

# 거대한 JSONB 또는 BYTEA 컬럼 있으면 defer
class User(Base):
    __tablename__ = 'users'
    id = Column(Integer, primary_key=True)
    name = Column(Text)
    profile_json = Column(JSONB, deferred=True)  # 접근 시만 로드

External links

Why SELECT * is bad

Exercise

코드베이스에서 프로덕션 path 의 SELECT * grep. 각각 결정: 필요? 아니면 명시 컬럼으로 대체. 이게 이전엔 불가능했던 covering 인덱스 가능하게 하는 곳 적기.

Progress

Progress is local-only — sign in to sync across devices.

← Previous쿼리 모양 먼저, 인덱스 두 번째 Next →N+1 쿼리 문제

이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

🔔 답글 알림 (로그인 필요)

로그인 — 댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.