bucket-sort logo bucket-sort

プログラミングとインフラエンジニアリングの覚え書き

  • Posts
  • About
  • Contact
  1. Home
  2. All Posts
  3. MySQL vs Auroraベンチマーク比較 (sysbench / db.t3.medium)

MySQL vs Auroraベンチマーク比較 (sysbench / db.t3.medium)

Feb 12, 2026 MySQL , Aurora , AWS bucket-sort

Aurora は RDS MySQL と比較して「優れている」と言われることが多い気がします。

ただ、その文脈のほとんどは、

  • 分散ストレージによる耐障害性
  • フェイルオーバー時間の短縮
  • Reader による読み取りスケールアウト

といった、冗長構成や可用性に関するものです。

一方で、「単体のデータベースとしてどの程度の処理性能を持っているのか?」という点については、 意外と具体的な話を聞く機会がありません。

Aurora はアーキテクチャ的に RDS MySQL とはかなり異なる実装になっているため、 もしかするとそのオーバーヘッドが OLTP ワークロードでは不利に働く可能性もあります。

実際のところどうなのか。

これまで自分では試したことがなかったので、 まずは同一インスタンスクラス上で MySQL (RDS) と Aurora MySQL を並べて、 純粋な処理性能にどの程度の差があるのかを確認してみることにしました。

本記事では sysbench を使用し、OLTP ベンチマークを実施した結果をまとめます。

動作環境

EngineInstancevCPUMemory
MySQL (RDS)db.t3.medium24 GiB
Aurora MySQLdb.t3.medium24 GiB

※ 両者とも Network Performance: Up to 2,085 Mbps

sysbench バージョン

sysbench 1.1.0-3ceba0b

テスト条件

  • テーブル数: 10
  • レコード数: 1,000,000 / table
  • スレッド数: 50
  • 実行時間: 60秒

テスト結果

oltp_read_write(読み書き混在)

EngineTPSQPSAvg Latency(ms)95% Latency(ms)
MySQL608.5612171.1682.12123.28
Aurora (Writer)475.999519.73104.85183.21

MySQL の方が

  • TPS: 約 +27%
  • 平均レイテンシ: 約 -22ms

oltp_read_only(読み取り中心)

EngineEndpointTPSQPSAvg Latency(ms)95% Latency(ms)
MySQL-942.0015072.0853.0673.13
AuroraReader754.6512074.4666.16155.80
AuroraWriter825.6113209.8160.51130.13

Reader endpoint 使用時は

  • TPS: 約 -20%
  • 95% latency は 2倍以上

oltp_point_select(単一行 SELECT)

QPS 上限の目安を見るテスト。

EngineEndpointQPSAvg Latency(ms)95% Latency(ms)
MySQL-23709.212.113.96
AuroraReader20833.792.405.18
AuroraWriter21530.102.324.82

Aurora は

  • 約 -10〜12% 程度のスループット低下

所感メモ

今回の条件では、

Aurora の方が一貫して遅い

という結果になりました。

特に

  • 読み書き混在(oltp_read_write)
  • Aurora Reader Endpoint

での差が大きく、

95% latency が顕著に悪化

しています。

これは Aurora の

  • 分散ストレージへの書き込み同期
  • ネットワーク越しのログ適用
  • Reader endpoint の読み取り整合性制御

などのオーバーヘッドが、 低スペックインスタンス(t3.medium)では 無視できないコストとして現れている可能性があります。

Aurora は「速い」のか?

Aurora は

  • フェイルオーバー高速化
  • Reader スケールアウト
  • ストレージ耐障害性(6-way replication)

などの 可用性・運用性のメリット を提供しますが、

単一ノードの OLTP ワークロードにおける 純粋なスループットでは RDS MySQL に劣るケースもある

ということが確認できました。

Aurora を選定する際には、

  • 可用性
  • スケーラビリティ
  • 運用負荷

といった非機能要件と、

単体ノード性能のトレードオフ

を踏まえて判断する必要がありそうです。

Aurora RDS MySQL AWS
← AWS WAFでレートベースのURLアクセス制限はできるのか? DNSSEC validationとは? →

  • Aurora MySQLのメリットを整理してみた(RDS MySQLとの違い) Jan 10, 2026
  • RDS MySQLとAurora MySQLをまたいでJOINできるのか調べてみた Jan 9, 2026
  • MySQLでレコードをDELETE / DROPしたらストレージ使用量は減るのか Jan 11, 2026
  • MySQLでレコードの平均サイズを求める Jan 8, 2026

  • 動作環境
  • sysbench バージョン
  • テスト条件
  • テスト結果
    • oltp_read_write(読み書き混在)
    • oltp_read_only(読み取り中心)
    • oltp_point_select(単一行 SELECT)
  • 所感メモ
  • Aurora は「速い」のか?

  • [WPF] XAML の構文を理解する: マークアップ拡張 Aug 28, 2026
  • [WPF] XAML の構文を理解する: 添付プロパティ Aug 27, 2026
  • [WPF] XAML の構文を理解する: プロパティ要素構文 Aug 26, 2026
  • [WPF] XAML の構文を理解する: 要素、属性、型変換 Aug 25, 2026
  • [WPF] XAML の構文を理解する: クラスとメンバーの見え方 Aug 24, 2026

  • C#170
  • .NET169
  • AWS27
  • Entity Framework Core24
  • Laravel16
  • Linux15
  • MySQL9
  • Apache8
  • PHP8
  • Data Access6
  • DynamoDB6
  • セキュリティ6
  • Nginx5
  • WordPress4
  • インフラ4
  • テスト4
  • Hugo3
  • .NET Framework1
  • Aurora1
  • Diagnostics1

  • C#
  • .NET
  • Entity Framework Core
  • AWS
  • Laravel
  • コレクション
  • PHP
  • セキュリティ
  • MySQL
  • WPF
  • Linux
  • パフォーマンス
  • LINQ
  • Apache
  • XAML
  • SQL Server
  • System.Collections.Generic
  • デリゲート
  • リフレクション
  • ADO.NET
  • Code Snippet
  • DbContext
  • DynamoDB
  • NoSQL
  • PHP-FPM
  • RDS
  • System.Collections
  • Windows
  • メタデータ
  • メモリ管理
  • CIL
  • DoS
  • Nginx
  • WordPress
  • アセンブリ
  • ラムダ式
  • 監視
  • 設計
  • Amazon Linux 2023
  • Delegate
  • Docker
  • IDisposable
  • Ipset
  • Iptables
  • LINQ to Objects
  • Migration
  • OPCache
  • Pointer
  • Reflection
  • System.Collections.Specialized
Powered by Hugo & Explore Theme.