Azure Linux VM에서 MySQL 성능 최적화

클라우드(Azure Linux VM 등)에 MySQL을 설치하면 기본 설정은 사양이 낮은 환경을 가정한 보수적인 값입니다. 서버 자원이 넉넉하다면 my.cnf의 몇몇 파라미터를 조정하는 것만으로 성능을 크게 끌어올릴 수 있습니다. 이 글은 Azure 문서에서 제시한 대표적인 InnoDB 튜닝 값을 정리하고, 각 파라미터가 무엇을 하는지 설명합니다.

튜닝 파라미터 요약

파라미터	기본값	최적화 예	역할
innodb_buffer_pool_size	(작음)	7G	데이터·인덱스를 메모리에 캐시 — 가장 중요
innodb_log_file_size	5M	512M	리두 로그 파일 크기 — 쓰기 처리량
max_connections	100	5000	동시 접속 허용 수
innodb_file_per_table	0	1	테이블마다 별도 파일로 저장
innodb_flush_log_at_trx_commit	1	2	커밋 시 로그 디스크 반영 방식
innodb_log_buffer_size	8M	128M	디스크 기록 전 로그 버퍼
query_cache_size	16M	0	쿼리 캐시 — 끄는 것이 오히려 유리

파라미터별 설명

• innodb_buffer_pool_size (핵심): InnoDB가 데이터와 인덱스를 담아 두는 메모리 캐시입니다. 여기 많이 담길수록 디스크 접근이 줄어 빨라집니다. 보통 전체 RAM의 60~70%로 잡습니다. 단일 DB 서버 튜닝에서 가장 효과가 큰 값입니다.
• innodb_log_file_size: 리두 로그 파일 크기. 크게 하면 쓰기 부하가 몰릴 때 체크포인트 빈도가 줄어 쓰기 성능이 좋아집니다. (변경 시 재시작·기존 로그 처리 주의)
• max_connections: 동시에 맺을 수 있는 연결 수. 너무 크면 메모리를 많이 먹으니 실제 필요량에 맞춰 늘립니다. 커넥션 풀 사용이 근본 해법입니다.
• innodb_file_per_table: 1로 두면 테이블마다 .ibd 파일로 분리 저장되어, 특정 테이블 삭제 시 공간 회수와 관리가 쉬워집니다. (현대 MySQL은 기본 1)
• innodb_flush_log_at_trx_commit: 안정성과 성능의 트레이드오프입니다. 1은 커밋마다 디스크에 기록해 가장 안전(ACID 완전), 2는 OS 캐시까지만 기록해 더 빠르지만 OS 크래시 시 최근 1초가량 손실 위험이 있습니다.
• innodb_log_buffer_size: 커밋 전 트랜잭션 로그를 담는 메모리 버퍼. 큰 트랜잭션이 많으면 늘려 디스크 I/O를 줄입니다.
• query_cache_size = 0: 쿼리 캐시는 동시성이 높으면 오히려 잠금 경합으로 성능을 떨어뜨립니다. 그래서 끄는 것이 권장되며, MySQL 8.0에서는 아예 제거되었습니다.

적용 예 (my.cnf)

[mysqld]
innodb_buffer_pool_size = 7G          # RAM의 60~70%
innodb_log_file_size = 512M
max_connections = 5000
innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 2   # 성능 우선(약간의 손실 위험 감수)
innodb_log_buffer_size = 128M
query_cache_size = 0                 # 쿼리 캐시 비활성화

주의: 위 값은 해당 VM 사양(특히 RAM)에 맞춰 조정해야 합니다. innodb_buffer_pool_size를 실제 메모리보다 크게 잡으면 스와핑으로 오히려 느려지거나 프로세스가 죽습니다. flush_log_at_trx_commit=2는 금융처럼 데이터 손실이 절대 안 되는 경우엔 1을 유지하세요.

정리

• 튜닝의 1순위는 innodb_buffer_pool_size(RAM의 60~70%).
• 로그 파일·버퍼를 키우면 쓰기 성능이 오른다.
• flush_log_at_trx_commit는 안정성(1) vs 성능(2)의 선택.
• 쿼리 캐시는 대부분 끄는 것이 유리(8.0에서 제거됨).
• 모든 값은 서버 사양과 워크로드에 맞춰 조정하고, 바꾼 뒤 실제 부하로 검증한다.