クイズ: インデックス

WHERE date(created_at) = '2026-07-26' 가 created_at 인덱스를 타지 못하는 이유는?

• 컬럼에 함수가 씌워져 인덱스의 정렬 순서를 그대로 쓸 수 없어서
• 날짜 타입에는 인덱스를 만들 수 없어서
• 등호 비교는 인덱스를 쓰지 않아서
• 통계가 오래되어서

복합 인덱스 (user_id, status, created_at) 가 있을 때 인덱스 탐색에 쓸 수 없는 조건은?

• WHERE user_id = 1
• WHERE user_id = 1 AND status = 'paid'
• WHERE status = 'paid'
• WHERE user_id = 1 AND status = 'paid' AND created_at >= '2026-01-01'

복합 인덱스의 컬럼 순서를 정하는 원칙으로 옳은 것은?

• 등호 조건 컬럼을 앞에, 범위 조건 컬럼을 뒤에 둔다
• 선택도가 높은 컬럼을 항상 뒤에 둔다
• 알파벳 순으로 둔다
• 크기가 작은 타입을 앞에 둔다

전체의 76퍼센트를 반환하는 조건에서 강제로 인덱스를 태우면 오히려 느려지는 이유는?

• 인덱스가 손상되기 때문
• 인덱스는 100행 이상을 반환할 수 없기 때문
• 통계가 갱신되지 않기 때문
• 매칭된 행마다 힙 페이지를 랜덤하게 방문해 결국 표 전체를 랜덤 순서로 읽게 되기 때문

부분 인덱스(WHERE 절이 붙은 인덱스)의 이점으로 옳지 않은 것은?

• 조건과 무관한 모든 조회가 빨라진다
• 인덱스 크기가 작아진다
• 조건에 맞지 않는 행의 INSERT 와 UPDATE 는 이 인덱스를 건드리지 않아 쓰기 비용이 준다
• 같은 컬럼에 대해 조건별로 여러 개를 만들 수 있다

Index Only Scan 이 가능하려면 무엇이 필요한가?

• 표에 인덱스가 하나만 있어야 한다
• 쿼리가 필요로 하는 컬럼이 모두 인덱스에 들어 있어야 한다
• 인덱스가 유니크해야 한다
• 표가 파티션되어 있어야 한다

인덱스를 추가할 때 함께 고려해야 할 비용으로 가장 적절한 것은?

• 인덱스를 거치느라 모든 SELECT 가 느려진다
• 인덱스가 자리를 차지해 표의 행 수 상한이 줄어든다
• 잠금 범위가 넓어져 트랜잭션 격리 수준이 낮아진다
• INSERT 와 DELETE 마다 모든 인덱스를 갱신해야 하고 계획 수립 시간도 늘어난다