2025-09-11

오늘 배운 것

MySQL에서 함수 기반 인덱스를 사용할 때 주의해야 할 점은 무엇인가요?

답변:

함수 기반 인덱스는 특정 컬럼을 변형하거나 계산한 결과에 대해 인덱스를 걸 수 있어, 가상 컬럼을 생성하거나 함수 표현식을 직접 지정할 수 있습니다. 다만 조건절에서 반드시 동일한 함수 표현식을 그대로 사용해야 옵티마이저가 인덱스를 활용할 수 있습니다. 예를 들어 CONCAT(first_name, ' ', last_name)으로 인덱스를 걸었다면 WHERE 절에서도 동일하게 사용해야 합니다.

멀티 밸류 인덱스(Multi-Value Index)는 어떤 특성을 가지고 있으며, JSON 데이터를 다룰 때 왜 필요한가요?

답변:

일반 인덱스는 레코드와 인덱스 키가 1:1 관계를 가지지만, 멀티 밸류 인덱스는 하나의 레코드가 여러 키 값을 가질 수 있습니다. 이는 JSON 타입 컬럼에서 배열 형태의 데이터를 효율적으로 검색하기 위해 도입되었습니다. 다만 단순한 WHERE 조건으로는 인덱스를 활용할 수 없고, MEMBER_OF(), JSON_CONTAINS(), JSON_OVERLAPS() 같은 전용 함수들을 사용해야 옵티마이저가 멀티 밸류 인덱스를 활용한 실행 계획을 수립합니다.

클러스터링 인덱스의 동작 원리와 장단점은 무엇이며, 서비스 환경에서 어떤 상황에 적합한가요?

답변:

클러스터링 인덱스는 프라이머리 키 값이 비슷한 레코드들을 물리적으로 묶어서 저장하는 방식입니다. 이로 인해 PK 검색과 범위 조회가 매우 빠르며, 세컨더리 인덱스도 PK를 함께 저장해 커버링 인덱스 효과를 얻을 수 있습니다. 반면 PK 변경이나 INSERT 시 레코드 위치가 바뀌어 쓰기 성능이 떨어지고, PK가 길면 세컨더리 인덱스 크기도 커지는 단점이 있습니다. OLTP 환경처럼 읽기 비중이 높은 서비스에서는 클러스터링 인덱스가 유리하며, PK는 반드시 명시하고 가급적 업무적으로 의미 있는 컬럼을 선택하는 것이 좋습니다.

유니크 인덱스와 일반 세컨더리 인덱스의 성능 차이는 언제 발생하며, 불필요한 유니크 인덱스를 생성하지 말아야 하는 이유는 무엇인가요?

답변:

읽기 성능에서는 유니크 인덱스와 일반 인덱스 차이가 거의 없고, 실제 속도 저하는 레코드 수가 많을 때 발생합니다. 차이는 쓰기 시점에 나타나는데, 유니크 인덱스는 중복 여부를 반드시 체크해야 하므로 CPU 연산과 잠금 경합이 추가 발생합니다. 이 때문에 데드락 빈도도 높아집니다. 따라서 유일성이 반드시 보장되어야 하는 컬럼에서만 유니크 인덱스를 사용해야 하고, 단순히 성능 향상을 목적으로 불필요하게 생성하는 것은 오히려 쓰기 성능을 저하시킬 수 있습니다.

외래키를 사용할 때 발생할 수 있는 잠금 경합(lock contention) 문제는 어떤 경우에 생기며, 이를 피하려면 어떤 점을 고려해야 하나요?

답변:

자식 테이블에서 외래키 칼럼을 변경할 때는 부모 테이블 레코드의 확인이 필요합니다. 이때 부모 레코드에 쓰기 잠금이 걸려 있으면 자식 변경이 대기합니다. 반대로 부모 테이블에서 키를 삭제할 때 자식 테이블이 해당 키를 참조 중이라면, 자식 레코드에 쓰기 잠금이 해제될 때까지 부모 변경이 지연됩니다. 이는 특히 ON DELETE CASCADE 옵션에서 많이 발생합니다. 따라서 외래키 설계 시 단순 무결성 보장뿐 아니라 쓰기 경합 발생 가능성까지 고려해야 하며, 경우에 따라 애플리케이션 단에서 무결성을 관리하는 방식도 검토해야 합니다.

MySQL에서 ORDER BY를 처리할 때 인덱스를 활용하는 방식과 Filesort를 활용하는 방식의 차이는 무엇이며, 실무에서 어떤 기준으로 선택해야 할까요?

답변:

인덱스를 이용한 정렬은 이미 인덱스가 정렬된 상태이므로 빠르고 스트리밍 방식으로 결과를 반환할 수 있습니다. 반면 Filesort는 쿼리 실행 중에 정렬을 수행해야 하므로 레코드 건수가 많을수록 응답 속도가 느려집니다. 하지만 인덱스를 생성하기 어려운 다중 조건 정렬이나 임시 테이블 결과 정렬 같은 경우는 Filesort를 쓸 수밖에 없습니다. 실무에서는 자주 쓰이는 ORDER BY 조건에는 인덱스를 설계하고, 드물게 사용하는 경우에는 Filesort로 처리하게 두는 것이 일반적입니다. 또한 sort_buffer_size 설정을 무작정 키우지 않고, 커넥션 수와 메모리 상황을 고려하는 것이 중요합니다.