MySQL January 2026 Performance Review

 

이 글은 Community MySQL, Percona Server for MySQL, MariaDB 의 최신 릴리스 버전을 대상으로 수행한 최근 성능 벤치마킹 결과를 설명하는 데 초점을 맞추고 있습니다.

이번 테스트에서는 여기(https://github.com/Tusamarco/blogs/blob/master/testmachine/testmachine.md)에 설명된 머신 환경을 사용했습니다.

 

Assumptions

테스트를 실행하는 방법은 매우 다양하며, 환경이나 MySQL 서버 설정같은 여러 요소를 어떻게 조정하느냐에 따라 결과가 달라질 수 있다는 점을 우리는 알고 있습니다. 하지만 같은 플랫폼에서 동일한 제품의 여러 버전을 비교한다면, MySQL 서버 설정을 변경하지 않는 한 각 버전은 성능이 잘 나오거나 나쁘게 나올 동일한 “기회”를 가진다고 보는 것이 논리적입니다.

이러한 이유로, 저는 각 솔루션에 동일한 조건과 기회를 제공한다는 목적 하에, 일관된 방식으로 필요한 요소들만 변경하면서 테스트를 수행했습니다. 또한, 제품이 기본 설정을 기반으로 배포된다는 것은, 해당 설정으로 충분히 테스트되었고 범용적인 사용에 가장 안전한 설정값이라고 제조사(또는 개발사)가 판단했다는 전제가 깔려 있다고 봅니다.

추가로 몇 가지 설정을 수정한 뒤 다시 테스트를 수행하여, 튜닝(최적화)이 성능에 어떤 영향을 미치는지도 함께 확인했습니다.

 

What tests do we run?

큰 틀에서 보면, 저는 다음과 같은 한 가지 테스트 세트를 실행했습니다:

• TPC-C (https://www.tpc.org/tpcc/) like

전체 테스트 방법론과 상세 내용은 여기에서 확인할 수 있으며, 실제로 사용한 명령어들도 제공되어 있습니다:

• Sysbench (https://github.com/Tusamarco/benchmarktools/blob/main/software/fill_sysbench_map.sh)
• TPC-C(https://github.com/Tusamarco/benchmarktools/blob/main/software/fill_tpcc_map.sh)

 

Why do I (normally) only publish TPC-C tests?  

보통 저는 sysbench 에서 흔히 수행하는 단일 기능 테스트보다는, 실제 사용 환경에 더 가까운 시나리오를 테스트하는 데 더 큰 관심이 있습니다.

물론 모든 실제 사용 사례에 완벽하게 들어맞는 벤치마크 테스트를 만드는 것은 불가능합니다. 그래서 우리는 항상 80% 의 법칙을 염두에 두어야 합니다.

MySQL/InnoDB를 사용한다면, Key/Value 형태보다는 OLTP 성격의 트래픽이 훨씬 많을 것이라고 예상합니다.

Sysbench 처럼 단일 기능 테스트는 회귀(regression) 지점을 찾는 데는 유용할 수 있습니다. 하지만 보다 넓은 시나리오를 보기 위해서는 TPC-C 가 더 적합합니다. TPC-C 테스트는 단순히 쓰기 부하가 더 강한 것뿐만 아니라(읽기/쓰기 비율이 50/50), relations, foreign keys, constraints 를 포함한 스키마 구조를 사용합니다. 요약하자면, 관계형 데이터베이스 관리 시스템의 일반적인 사용 방식에 훨씬 더 가깝습니다.

다만 이번에는 상황이 조금 다릅니다. 공정성을 위해 sysbench 의 단일 테스트도 함께 깊이 살펴볼 필요가 있습니다. 이로 인해 이전 글들보다 블로그 글이 조금 길어지긴 했지만, 그럴 만한 가치가 있다고 생각하며, 그 이유는 곧 확인하실 수 있을 것입니다.

 

Results

수행된 테스트는 두 가지 서로 다른 트랜잭션 격리 수준에서 진행되었습니다. 하나는 Repeatable Read, 다른 하나는 Read Committed 입니다. 전자는 MySQL/InnoDB 의 기본값이며, 후자는 많은 잘 알려진 다른 RDBMS의 기본값입니다.

먼저, Community MySQL 과 Percona Server for MySQL 이 이전 버전들과 비교했을 때 어떤 성능을 보이는지를 살펴보겠습니다. 특히, 한동안 문제가 되었던 사건 이후의 변화에 주목할 필요가 있습니다
(참고: https://www.tusacentral.net/joomla/index.php/mysql-blogs/256-sakila-where-are-you-going).

이번에는 MySQL 5.7을 완전히 제외했습니다. 이미 오래전에 EOL(지원 종료) 되었기 때문입니다. (여러분, 아직 사용 중이라면 반드시 벗어나셔야 합니다. 방법을 모르신다면 저희에게 도움을 요청하세요.)

늘 그렇듯이, 많은 말보다 하나의 이미지가 더 명확하게 설명해 줍니다:

 

또한, 여기에 공개된 이전 결과와 이러한 추세(절대값이 아닌 추세 자체)를 비교해 볼 수도 있습니다.

이제 이 이미지들에 대해 조금 코멘트를 해보겠습니다.

첫 번째로 짚고 넘어가야 할 점은, 요즘 시스템은 반드시 확장성에 대비되어 있어야 한다는 것입니다. 이건 더 이상 논쟁의 여지가 없습니다. 또한 1024 스레드까지만 수행하는 벤치마크는 충분하지 않습니다. 실제 환경에서는 4000개 이상의 커넥션이 존재하는 경우도 흔합니다. 그런 점을 고려하면, 부하를 128 스레드 이하에서 멈추는 벤치마킹은 전혀 의미가 없습니다.

이 점은 다음 섹션에서 매우 명확해질 것입니다. 우선 현재로서 관찰할 수 있는 부분은, Percona Server 와 Community MySQL 의 성능이 매우 근접하다는 점입니다. 그 미세한 차이는 변동성 범위 안에 있으므로, 통계적으로 의미가 없습니다. 이는 두 제품이 상당 부분의 코드를 공유하고 있기 때문에 충분히 예상 가능한 결과입니다. 여기서 중요한 점은, Percona Server 는 MySQL Community 와 유사하거나 동일한 성능을 제공하면서도, MySQL Enterprise 에만 존재하던 기능들까지 포함한, 더 풍부한 기능 세트를 제공한다는 것입니다.

두 번째로 언급할 점은, 이전 테스트들에서 MySQL 이 서버 동작을 안정화했을 뿐만 아니라, 스케일링 과정에서 발생하던 성능 저하를 방지하기 위한 중요한 수정들을 수행했다는 사실입니다.

그리고 이제는, 최신 버전들이 트래픽을 계속해서 처리하면서 더 높은 수준까지 확장할 수 있는 능력을 보여주고 있습니다. 요약하자면, 전반적으로 상황은 양호하며, 최소한 과거에 비해서는 훨씬 나아졌다고 볼 수 있습니다.

이제 MariaDB 11.8.5를 추가하고, MySQL/Percona 8.4 와 9.5 에 집중해 보겠습니다.

 

이 결과, 별로 좋아 보이지 않죠? 겉으로 보기에 MariaDB 는 32 스레드까지는 매우 잘 동작하다가, 그 이후에는 갑자기 멈춘 것처럼 트래픽을 처리하지 못하는 것으로 보입니다.

만약 동시성을 최대 32 스레드로 제한했다면, MariaDB 의 포화 지점을 관찰하지 못했을 것이고, 그 결과 부정확한 테스트 결과와 잘못된 결론에 이르렀을 것입니다. 이것이 바로 제가 항상 먼저 포화 지점을 식별한 뒤에 테스트 스케일을 늘리는 이유입니다.

그렇다면 왜 이런 현상이 발생했을까요? TPC-C 계열의 테스트는 하나의 트랜잭션 안에서 읽기와 쓰기를 50/50 비율로 동시에 수행하며, 동시 실행되는 작업들을 포함한다는 점을 기억해야 합니다. 이는 바쁜 실제 시스템에서 벌어지는 상황을 더 잘 반영합니다.

어쨌든 저는 이러한 MariaDB 의 동작 방식이 매우 이상하게 느껴졌고, 그래서 보유하고 있던 모든 sysbench  테스트도 함께 실행해 보았습니다. (전체 결과를 보려면 여기를 참고하세요. https://www.tusacentral.net/joomla/static/performance/2026_january/data_sysbenchfrom8.4to9.5_sysbench.html )

이 실험에서 드러난 것은 완전히 다른 양상이었습니다. 개별(단일) 테스트를 실행했을 때는, MariaDB 가 매우 좋은 성능을 보였고, 특히 읽기 작업에서는 MySQL 이나 Percona Server 를 능가하는 경우도 많았습니다.

예를 들어, 제가 모든 range 테스트를 실행하는 range tests all 같은 사례를 살펴보겠습니다.

보시는 것처럼 MariaDB 는 매우 좋은 성능을 보이고 있으며, 특히 unordered pages(비정렬 페이지) 의 경우에는 MySQL/Percona 보다 영향을 덜 받는 모습입니다.

그리고 이것이 모든 읽기 작업 전반에 걸친 추세입니다. 그렇다면 쓰기 성능은 어떨까요?

일부 경우, 예를 들어 hotspot 이 존재하는 in-list update 상황에서도 MariaDB 는 여전히 좋은 성능을 유지하고 있습니다:

 

하지만 hotspot 이 없는 경우, 즉 쓰기 작업이 전체 데이터셋에 고르게 분산될 때에는:

 

 

insert/delete 작업을 사용할 경우에는 이 현상이 더욱 분명하게 드러납니다:

 

 

마지막으로, 읽기/쓰기 작업을 함께 수행하는 테스트들을 종합해 보면:

 

 

TPC-C 테스트에서 보았던 것과 매우 유사한 동작 패턴을 확인할 수 있습니다.

저는 MariaDB 가 쓰기 작업에서 이렇게 크게 성능이 떨어지는 정확한 원인까지는 상세히 분석하지는 않았지만, 제 직감으로는 MariaDB 에서 수행한 InnoDB 버퍼 풀 구조 변경을 원인으로 보고 있습니다. 이는 아마도 MariaDB 가 읽기 성능에서 더 좋은 결과를 보이는 이유이기도 할 것입니다.

물론 저는 재튜닝 및 재테스트를 함께 진행하고자 하는 MariaDB 관계자들과의 협업에도 열려 있습니다. 원하신다면 언제든지 연락 주세요.

 

Conclusions

TPC-C 계열 테스트로 수행한 결과들은, 과거에 있었던 MySQL 관련 논란은 이제 끝났다고 봐도 된다는 점을 확인시   켜 줍니다. 동시에, 더 나은 성능을 향한 경쟁이 다시 열렸다는 신호이기도 하며, 저는 Percona 가 다시 한 번 전력 질주하여 엔터프라이즈 기능뿐만 아니라 의미 있는 성능 향상도 추가해 주기를 기대하고 있습니다.

현재 시점에서 보면, MySQL/Percona 9.5 는 안정성과 확장성 측면에서 가장 뛰어난 MySQL 계열 버전임을 다시 한번 입증했습니다.

또한 MariaDB 의 구현 방식에 대해 좀 더 깊이 조사할 필요가 있다고 생각합니다. 특히 읽기 성능은 매우 뛰어난 반면 쓰기 성능이 크게 떨어지는 원인이 무엇인지를 명확히 해야 합니다. 이미 LAMP 시대처럼 읽기 위주인 환경은 지났고, 요즘의 데이터베이스 부하는 다수의 스레드에서 읽기/쓰기 작업이 동시에 수행되는 것이 일반적입니다. 그런 환경에서 MariaDB 와 같은 동작 특성은 받아들이기 어렵습니다. 다만, 해당 부분을 집중적으로 분석한다면 병목 지점을 찾아 수정할 수 있을 것이라 확신합니다.

마지막으로, 저는 이 제품이 앞으로 더욱 발전하는 모습을 빨리 보고 싶습니다. 커뮤니티가 주도적으로 나서서 변화를 이끌어 달라는 우리의 요구가, 우리가 기대하는 결과로 이어지기를 진심으로 바랍니다.

그럼, 즐거운 MySQL(그리고 MariaDB) 생활 되세요!

 

 

 

자유롭게 댓글을 달아주세요! 언제나 환영합니다.
기타 문의:  info@neoclova.co.kr
네오클로바 기술블로그 홈 바로가기: https://neoclova.net
네오클로바 홈페이지: http://neoclova.co.kr