이 글에서는 MySQL 설치 직후 적용하면 더 빠르고 안정적인 성능을 얻을 수 있는 핵심 성능 튜닝 설정들을 살펴봅니다.
사전 준비 사항
MySQL이 이미 설치되어 있다고 가정하고 진행합니다. 성능 튜닝 설정을 시작하기 전에 몇 가지 팁을 먼저 확인하세요.
경험이 많은 IT 담당자라도 실수로 인해 여러 문제가 발생할 수 있습니다. 따라서 이 글의 권장 설정을 적용하기 전에 아래 사항을 미리 숙지해 두면 문제를 예방할 수 있습니다.
설정은 한 번에 하나씩만 적용하여 변경 효과를 정확하게 평가합니다.
대부분의 변경 사항은 "SET GLOBAL" 명령으로 런타임에 적용할 수 있어 매우 간편하며, 문제가 생기면 손쉽게 되돌릴 수 있습니다. 이후 안정성이 확인되면 설정 파일에 영구적으로 반영하면 됩니다.
MySQL 서비스를 재시작해도 설정이 적용되지 않는다면 설정 파일 경로가 잘못되었거나 해당 설정이 올바른 섹션에 위치하지 않은 것일 수 있습니다.
MySQL은 중복된 설정을 허용하지 않습니다. 변경 이력을 체계적으로 관리하려면 Git 같은 버전 관리 시스템을 활용하는 것이 좋습니다.
주요 MySQL 성능 튜닝 설정
아래는 [mysqld] 섹션에서 구성할 수 있는 주요 성능 튜닝 설정들입니다. 가능하다면 설치 시점부터 이 설정들을 함께 구성해 두는 것이 좋습니다.
innodb_buffer_pool_size – InnoDB를 사용한다면 설치 직후 가장 먼저 확인해야 할 가장 중요한 설정입니다. 버퍼 풀은 데이터와 인덱스를 캐싱하는 공간으로, 크기를 충분히 크게 설정하면 대부분의 읽기·쓰기 작업에서 디스크가 아닌 메모리를 사용하게 됩니다. 일반적으로 8GB RAM 기준으로 5~6GB 정도로 설정하는 것이 권장됩니다.
innodb_log_file_size – 리두 로그(redo log) 크기를 결정하는 설정입니다. 리두 로그는 쓰기 작업을 빠르고 내구성 있게 유지하며, 크래시 복구(crash recovery) 시에도 중요한 역할을 합니다. MySQL 5.1 이전 버전에서는 성능 향상을 위해 큰 리두 로그가 필요했지만, 그만큼 크래시 복구 속도에는 불리했습니다. MySQL 5.5부터 크래시 복구 성능이 개선되었고, 리두 로그 크기 제한은 5.5에서 4GB였으나 5.6부터는 상한이 제거되었습니다.
max_connections – "Too many connections" 오류를 방지하려면 max_connections 값을 늘려야 합니다. 기본값은 151입니다. 다만 값이 너무 크면 동시 연결과 활성 트랜잭션이 많아질 때 서버가 응답하지 않을 수 있다는 점이 단점입니다.
innodb_log_buffer_size – 아직 커밋되지 않은 트랜잭션을 보관하는 버퍼의 크기입니다. 기본값은 1MB이며, TEXT/BLOB 같은 대용량 필드를 포함한 큰 트랜잭션이 많으면 버퍼가 빠르게 차오르면서 불필요한 디스크 I/O 부하가 발생합니다. 이 경우 innodb_log_buffer_size를 늘려 주는 것이 좋습니다.
innodb_flush_method – 로그와 데이터를 디스크에 플러시하는 방식을 제어합니다. 쓰기 캐시(write-back cache)가 있는 RAID 컨트롤러를 사용하는 환경이라면 O_DIRECT가 대부분의 시나리오에서 가장 좋은 선택입니다. Sysbench 같은 벤치마크 도구를 활용하면 자신의 환경에 맞는 최적값을 찾는 데 도움이 됩니다.
query_cache_size – 쿼리 캐시는 동시성이 어느 정도만 높아져도 병목 지점이 되기로 악명이 높습니다. 처음부터 비활성화하는 것이 가장 좋으며, 비활성화하려면 query_cache_size=0으로 설정하면 됩니다. MySQL 5.6부터는 기본적으로 비활성화되어 있습니다. 캐시 대신 Memcached나 Redis를 활용해 애플리케이션 수준에서 응답 속도를 개선하는 방법도 고려할 수 있습니다. 만약 이미 쿼리 캐시를 활성화한 상태로 운영 중이고 특별한 문제가 없다면 굳이 끌 필요는 없지만, 비활성화할 때는 신중하게 접근해야 합니다.
log_bin – 서버를 복제(replication) 마스터로 구성할 때 필수적인 설정입니다. 단일 서버 환경에서도 최신 백업을 복원한 후 바이너리 로그를 적용하는 PITR(Point-In-Time Recovery)이 가능해지므로 매우 유용합니다. log_bin이 활성화되면 로그가 계속 누적되므로 디스크 공간 확보를 위해 오래된 로그를 정리해야 합니다. PURGE BINARY LOGS 명령을 사용하거나 expire_logs_days 설정으로 며칠 후 자동 삭제될지 지정할 수 있습니다.
skip_name_resolve – 클라이언트가 MySQL 서버에 접속할 때 서버는 호스트명 조회(DNS lookup)를 수행합니다. DNS가 느리면 접속 속도도 함께 느려지므로, skip_name_resolve 옵션으로 서버를 시작해 DNS 조회를 비활성화하는 것이 좋습니다. 단, 이 옵션을 사용하면 GRANT 문 작성 시 호스트명 대신 IP 주소를 사용해야 하므로, 기존 애플리케이션 구성에 이 설정을 추가할 때는 주의가 필요합니다.
이 글에서는 innodb_buffer_pool_size, innodb_log_file_size, max_connections, innodb_log_buffer_size, innodb_flush_method, query_cache_size, log_bin, skip_name_resolve 설정을 통해 MySQL의 읽기·쓰기 성능을 개선하는 방법을 살펴보았습니다. 설정은 한 번에 하나씩 적용하고 효과를 검증하면서 진행하는 것이 가장 안전한 방법입니다.