MySQL 미드레벨 기술면접

INSERT/UPDATE/DELETE 시 데이터 변경과 함께 모든 인덱스를 함께 갱신해야 하므로 쓰기 성능이 저하됩니다. 인덱스가 많을수록 B-Tree 구조 재조정과 페이지 분할이 빈번해져 오버헤드가 증가합니다. 실무에서는 쿼리 패턴 분석을 통해 자주 사용되는 WHERE, JOIN, ORDER BY 조건에만 인덱스를 생성하며, sys.schema_unused_indexes 뷰나 performance_schema를 활용해 사용되지 않는 인덱스를 주기적으로 모니터링하고 제거합니다. 일반적으로 테이블당 5~7개 이하의 인덱스를 권장하며, 쓰기 작업이 빈번한 OLTP 환경에서는 더욱 신중하게 결정해야 합니다.

긴 트랜잭션은 Undo Log가 계속 쌓여 테이블스페이스가 비대해지고, 다른 트랜잭션들이 오래된 데이터 버전을 유지해야 해 MVCC 오버헤드가 증가합니다. 또한 잠금을 오래 유지하여 다른 트랜잭션의 대기 시간이 길어지고 데드락 가능성이 높아집니다. information_schema.innodb_trx 테이블에서 trx_started 시간을 확인하거나, performance_schema의 events_transactions_current를 모니터링하여 긴 트랜잭션을 식별할 수 있습니다. 애플리케이션에서는 트랜잭션 범위를 최소화하고, 외부 API 호출이나 파일 I/O는 트랜잭션 밖에서 처리하며, 대량 작업은 배치 단위로 커밋하는 패턴을 사용합니다.

ORDER BY 절의 컬럼이 인덱스에 포함되어 있고 인덱스 순서와 정렬 방향이 일치하면 인덱스를 사용해 정렬 없이 결과를 반환할 수 있습니다. 하지만 ORDER BY 컬럼이 인덱스에 없거나, WHERE 조건과 ORDER BY 컬럼이 다른 인덱스를 사용하거나, 정렬 방향이 혼합된 경우 Using filesort가 발생합니다. filesort는 sort_buffer_size 메모리에서 정렬을 수행하며, 데이터가 크면 디스크 임시 파일을 사용해 성능이 저하됩니다. 개선 방법으로는 WHERE와 ORDER BY를 함께 고려한 복합 인덱스 생성, sort_buffer_size 증가, 또는 LIMIT를 사용해 정렬 대상 레코드 수를 줄이는 방법이 있습니다.

ENUM은 내부적으로 정수로 저장되어 1~2바이트만 사용하므로 저장 공간이 효율적이고, 정수 비교로 인해 조회 성능이 빠릅니다. 하지만 값 추가나 수정 시 ALTER TABLE이 필요하고, 순서 변경이나 값 삭제가 어려워 유지보수성이 떨어집니다. VARCHAR는 문자열 그대로 저장되어 공간을 더 사용하지만, 애플리케이션에서 자유롭게 값을 관리할 수 있어 유연합니다. 실무에서 상태값이나 카테고리처럼 변경이 거의 없고 선택지가 명확한 경우 ENUM을 사용하고, 자주 변경되거나 다국어 지원이 필요한 경우 VARCHAR와 별도 코드 테이블을 사용하는 것이 적합합니다.

먼저 performance_schema의 events_statements_summary_by_digest를 확인해 CPU 시간이 긴 쿼리를 식별하고, SHOW PROCESSLIST로 현재 실행 중인 쿼리와 상태를 확인합니다. sys.statements_with_runtimes_in_95th_percentile로 지연이 큰 쿼리를 분석하고, SHOW ENGINE INNODB STATUS로 잠금 경합이나 세마포어 대기 상황을 확인합니다. 원인별로 1) 비효율적인 쿼리는 인덱스 추가나 쿼리 리팩토링, 2) 동시 접속 급증은 Connection Pool 조정이나 Read Replica 추가, 3) 배치 작업 충돌은 스케줄 분산, 4) 통계 정보 오래됨은 ANALYZE TABLE 실행으로 해결합니다. 또한 innodb_buffer_pool_size와 thread_cache_size 같은 파라미터 튜닝도 고려합니다.