データベース

MySQL バージョンのパフォーマンス: 速度とスケーラビリティへの影響

MySQLバージョンのパフォーマンス は、応答時間、クエリのスループット、および負荷時のスケーリングという点で測定可能です。この記事では、実際のベンチマークを使用して、MySQL 5.7、8.0、8.4、9.1、9.2 の負荷時のパフォーマンスを示します。 スピード とスケーラビリティ、そしてどのチューニング・ステップが有意義なのか。.

中心点

バージョン select: 8.0+は、高い同時実行性で著しく優れたスケールを発揮する。.
クオップス-ゲイン：糸数の増加に伴い、最大+50%対5.7。.
8.4/9.x書き込みとJOINの最適化。.
チューニングバッファプール、スレッド、ソート、ログのパラメータを正しく設定。.
テストターゲットハードウェア上で自身のsysbenchが動作することを検証する。.

MySQLパフォーマンスの基本

私は、MySQL を高速化するコアトピックに重点を置いています： クエリ, インデックス、メモリ、IO。InnoDBは、優れたバッファ管理、クリーンなスキーマ設計、正確なインデックス戦略から大きな恩恵を受けています。最近のバージョンは、スケジューラのオーバーヘッドを減らし、ビンログ操作を改善し、待ち時間を短縮しています。私は、特にJOINプラン、インデックススキャン、スレッドコントロールで測定可能な効果を測定しています。パフォーマンスを求めるのであれば、以下を優先してください。 スキーム ハードウェアのアップグレードの前に.

MySQL 5.7と8.0の比較: スケーリングとQPS

並列度が低い場合、5.7は堅実な性能を発揮しますが、スレッド数が増えるにつれて スケーリング 8.0はより高い同時実行性に耐えることができ、OLTPワークロードのQPSは5.7に比べて30～50%向上することが多い。降順インデックスはファイルソートを回避し、読み込みを顕著に高速化する。私は、InnoDBの行操作とリード/ライト混在トランザクションで最大の向上を実感している。しかし、スループットを向上させるには、もう少しコストがかかります。 CPU, これは、現在のハードウェアでは通常許容範囲内である。.

8.0 エンタープライズとコミュニティ：ベンチマークが示すもの

Sysbench の測定では、8.0.35 Enterprise は多くの場合 21-34% 高い値を達成しています。 クオップス コミュニティ版よりも優れている。その利点は、最適化された内部構造と優れたスレッド処理にある。初期の8.0リリースではDELETE/UPDATEでリグレッションが発生することがありましたが、後のパッチで解消されました。そのため、私はパッチレベルを考慮し、特に重要なクエリをテストしています。予測可能な方法でスケールする場合、より高いクエリに対する付加価値を計算します。 CPU-ロードとエディションの決定.

8.4と9.xの進歩が一目でわかる

8.4.3と9.1.0では、binlogの依存性追跡の変更により、書き込み作業負荷が大幅に増加し、更新で約19.4%増加した。JOINの最適化(+2.17%)とインデックスの範囲スキャン(+2.12%)により、さらに増加しました。多くのワークロードにおいて、書き込みで+7,25%、読み込みで+1,39%の向上が見られます。9.1.0は、8.4.3との差はわずか（≒0.68%）ですが、8.0.40に近づいています。TPC-Cのようなシナリオでは、9.2が最も優れているとみなされることが多い。 スケーラブル 特に128スレッドを超えるとそうだ。.

バージョン	コア・アドバンテージ	典型的な利益	備考
5.7	低いコンカレンシー	-	操作が簡単で、高負荷時にはスケールが小さくなる。.
8.0	下降インデックス, より良いスレッド	+30-50% QPS 対 5.7	CPUの利用率が高く、OLTPでは明らかな利点がある。.
8.4.3	ビンログ依存の最適化	書き込み +7,25%	JOINとレンジスキャンでさらなる利益。.
9.1.0	微調整オプティマイザーおよびロギング	≈-0.68% vs 8.4.3	8.4.3に近く、一貫した結果。.
9.2	高いスレッド数	128スレッド以上のトップ	非常に良いスケーリング高負荷運転時.

私はこの表を、まず作業量、次にバージョン、そして微調整という意思決定の補助として使っている。書き込みが多い作業をしている人は、8.4/9.xをより強く感じるだろう。読み込み主体のアプリケーションは、すでに8.0から顕著な恩恵を受けている。着実な成長のためには、9.2が安全策であることに変わりはない。依然として重要なのは、クリーンな 測定戦略 ターゲット・ハードウェアごとに。.

OLTPベンチマークを正しく読み、使用する

私はベンチマークを単独で評価するのではなく、自分自身のレイテンシとスループット目標の文脈で評価する。リード・オンリー、ポイント・セレクト、リード・ライトでは挙動が異なるため、異なる分析が必要になる。解釈. .QPSのピークは、95/99パーセンタイルが安定している場合にのみ説得力を持つ。本番負荷では、短い SELECT と集中的な UPDATE/INSERT フェーズが混在することが多い。初期最適化ステップについては、コンパクトなチューニングのヒント, 深く掘り下げる前にね。.

チューニング：効果的なコンフィギュレーション

をセットした。バッファプール parallel_query_threadsは、並列性が高すぎると魅力的だが、依存関係が制限されるため、コントロールしながら使っている。sort_buffer_sizeは、必要に応じて増やし、グローバルな誇張は避けている。Binlogの設定とフラッシュ戦略は、レイテンシとフラッシュに影響する。 スループット 目につく。回転を続ける前に、すべての変化を測定する。効果.

見落としがちなコンフィグ・レバー

やり直し／取り消し： innodb_log_file_size そして innodb_redo_log_capacity リカバリ時間を超えない範囲でチェックポイントが頻繁に押されないようにする。書き込みフェーズについては、4～8GB以上のREDOを出発点として計算し、REDOレベル測定で検証する。.
フラッシュ/IO： innodb_flush_neighbors 最近のSSD/NVMeでは無効になっている、, innodb_io_capacity(_max) を実際のIOPSに変換することで、LRUフラッシュが波状的に発生しないようにする。.
変更バッファ：多くのセカンダリ・インデックス書き込みでは バッファーの変更 実際にプレッシャーが和らぐのか、それとも移動するのか、モニタリングで確認すること。.
Tmpテーブル： tmp_table_size そして max_heap_table_size 頻繁に使用される小さなソートがRAMに残るように、大きな稀なソートを最適化する。.
ジョイン/ソート 結合バッファサイズ そして ソート・バッファ・サイズ スレッドごとに割り当てられるので、中程度にしかならない。私はインデックスとプランを最初に最適化し、バッファは最後に最適化する。.
耐久性がある： sync_binlog, innodb_flush_log_at_trx_commit そして binlog_group_commit 意識的に：1/1が最大限の安全であり、それ以上の値は計算可能なリスクとともにレイテンシを減少させる。.

ストレージエンジンとワークロードパターン

InnoDBが標準ですが、ワークロードは大きく異なります。私は、セカンダリ・インデックス、FK制約、ACID機能が、実際にInnoDBで使用されるものであるかどうかをチェックしています。 使用例 をサポートする。古いデータをアーカイブすることで、プライマリテーブルの負荷を減らし、作業セットを小さく保つことができる。エンジンの背景知識については、以下のようなコンパクトな概要がある。 InnoDB 対 MyISAM. .最終的に重要なのは、エンジン、インデックス、クエリが一体となって、首尾一貫した プロフィール その結果.

リスクのないアップグレードパスを計画する

5.7→8.0→8.4/9.xと、リグレッションチェックを挟みながら段階的にアップグレードしています。変更の前に、スキーマの変更を凍結し、繰り返し可能な テスト. .そして、クエリプラン、パーセンタイル、ロックを比較する。ブルーグリーン戦略やリードレプリカのフェイルオーバーはダウンタイムを減らす。適切な計画を立てた人は、すぐに新しい特徴そしてより高い効率。.

モニタリングとテスト方法論

私はSysbenchで測定し、Performance SchemaやPercona Toolkitなどのツールからメトリクスを補足しています。高い平均値よりも決定的なのは、95/99パーセンタイルと分散. .クエリーダイジェスト分析により、高価なパターンがスケールする前に発見される。実運用負荷のリプレイは、合成テストのみよりも優れた情報を提供します。継続的な モニタリング アップグレードは盲目のままである。.

MariaDBとMySQLの比較：現実的な選択

MySQL8.0はOLTPと高スレッド数で輝き、9.2は>128スレッドで最強である。 スケーリング を見せる。私は作業負荷に応じて決めている：小さなトランザクションが多く書き込みが多いか、読み込みが多いOLTP負荷が混在しているか。構成とスキーマが適切であれば、どちらのシステムも信頼できる結果をもたらします。どちらを選ぶかは ワークロード, チームの専門知識とロードマップ.

プランの安定性、統計、インデックスのトリック

アップグレードによってスループットが向上するだけでなく、新しいオプティマイザーのヒューリスティックがもたらされることはほとんどない。私は分析と統計を意識的にコントロールすることで、プランの安定性を確保している。. 永続的な統計 と正規の アナライズテーブル 現実的なカーディナリティを維持する。データ分布が大きく歪んでいる場合は ヒストグラム (8.0+では)一般的なインデックスの拡張よりも多いことが多い。機密性の高いクエリに対しては オプティマイザーのヒント, しかし、将来のバージョンが自由に最適化を続けられるように、控えめにしている。.

見えないインデックス 私はリスクなしでインデックス除去の効果をテストするために使っている。. 機能指標 そして 生成されたコラム 式やJSONフィールドに対する頻繁なフィルタリングを高速化し、高価なフィルタリングを回避します。 ファイルソート/tmp-パスの変更。ページ分割やセカンダリーインデックスの書き込みが手に負えなくならないように、私はプライマリーキーを単調（AUTO_INCREMENTまたは時間ベースのUUIDバリアント）にしている。ランダムなUUIDを使用している場合は、挿入の局所性とインデックスへの変更の影響を測定してください。 フラッシュ-最後だ。.

パフォーマンス重視のレプリケーションとフェイルオーバー

高い書き込みレートには列-意味のあるグループ化 (グループコミット)とのトレードオフを測定する。 sync_binlog=1 と0/100でスケーリングされる。 スレーブ並列ワーカー (レスポンス。. レプリカ並列ワーカーの場合、8.0以上がかなり良い。 依存関係の追跡 は適切に機能する。フェイルオーバーシナリオでは、セミシンクはRTOを加速させるが、レイテンシを増加させる可能性がある。.

私は細部にまで注意を払う： ビンログ_チェックサム と圧縮はCPUコストがかかるが、IOは節約できる；; binlog_expire_logs_seconds ログの増加を防ぐ。レプリカには 読み取り専用 乖離を避けるため、厳密にテストする。 遅延複製 を使用することができる。負荷のピーク時には、SLOとRTOが許す限り、ビンログフラッシュパラメータを一時的に緩和することが役立つ。.

接続とスレッド管理

多くのボトルネックは、ストレージで発生するのではない。 接続処理. .私は 最大接続数 現実的な（最大ではない）、増加 スレッドキャッシュサイズ を何よりも頼りにしている。 接続プール アプリケーションの私は、短くて頻繁なコネクションを、裸のコネクション数ではなく、プーリングによってスケーリングしている。. ウェイトタイムアウト そして 対話型タイムアウト 死体を避けるように制限し、観察している。 スレッドランニング 対 スレッド接続.

並列性が高い場合は、選択的にスロットルを操作する： innodb_thread_concurrency 通常は0（自動）のままだが、ワークロードが過度にコンテキストを切り替える場合は介入する。. テーブル・オープン・キャッシュ そして テーブル定義キャッシュ ホットスキーマが常にリオープンされないようにするためだ。8.0+では、スケジューラーはより良いミューテックスの恩恵を受けている。 とどろく群れ, ハードループの代わりにアプリケーションバックオフと指数関数リトライを使用することによって。.

ハードウェア、OS、コンテナの現実

MySQLは、基盤が正しい場合にのみ最新のハードウェアを利用する。NUMA マシンでは、RAM をピン留め（インターリーブ）するか、プロセスをいくつかのノードにバインドしてノード間のレイテンシを回避する。. 透明な巨大なページ IOスケジューラはなし (または. mq-デッドライン. .CPUのスケーリングをパフォーマンスガバナーに固定し、周波数の変化からレイテンシのピークが生じないようにしている。.

ファイルシステムレベルでは、クリーンアライメントとマウントオプションに注意を払い、複数のNVMeが利用できる場合は、binlog、REDO、データを分離します。コンテナでは、リソースをハードセットし（CPUセット、メモリ制限）、ストレージレイヤーのFsync動作をテストする。Cgroupのスロットリングがなければ、想定される「DBのバグ」を説明できない。仮想化する人は、割り込み制御、書き込みキャッシュ、バッテリーバックアップコントローラーをチェックし、以下のことを検証する。 O_DIRECT が実際に通過する。.

データモデル、文字セット、ストレージ効率

8.0+にアップグレードする場合 utf8mb4 標準 - 互換性は良いが、インデックスと行のサイズが大きくなる。VARCHARの長さをチェックし、照合順序を意図的に設定し、ソートコストをコントロールする。データ型を小さくしている（例えば. INT の代わりに ビッグポイント, を使用する。 ジェネレイテッド カラムで計算されたフィルタをインデックス化できるようにする。そうでない場合は、生の圧縮レベルよりも、ホットセットの削減（アーカイブ、パーティショニング）から得るものの方が多い。.

プライマリ・キーはパフォーマンス・ポリシーである。 地域の挿入 ランダムキーはレイテンシーと書き込みの増幅を促進する。セカンダリーインデックスは定期的にクリーンアップする。インデックスを維持する前に、目的とクエリの頻度を評価する。.

安全にテストし、安全に展開する

私は段階的にリリースを構成しています：同一の8.0/8.4/9.xインスタンスに対するシャドウトラフィック、そして段階的なトラフィックシフト（Canary、5-10-25-50-100%）。ダイジェスト分析を使ってクエリプランを比較し、乖離がある場合は、ヒストグラム、ヒント、インデックスがリグレッションパスを閉じるかどうかを明らかにします。重要なポイント: 8.0は新しい データ辞書; 5.7へのジャンプは事実上不可能であり、そのため最終的なカットオーバーの前には必ずバックアップが必要となる。.

フェイルオーバーをシミュレートし、リスタート時間や実際のレプリケーションの挙動をシミュレートし、巻き戻しの可能性がないかログの保持をチェックする。. ロールバック コンフィグ切り替え、機能フラグ、DBバージョンだけでなく、以前のビルドへの高速ロールバックなどだ。そして、すべてのチューニングステップをメトリクスで文書化します。ポイントを測定しなければ、次の反復のための学習効果はありません。.

要約と決定ガイド

私が言えることは、8.0は5.7に比べて大きなQPSの飛躍をもたらし、8.4/9.xは書き込みとJOINをさらに推し進める。128スレッド以上を計画している人は、9.2と一貫性のあるスレッドが大きな利益をもたらすだろう。 チューニング. .私は、バッファプールのサイズ、適切なインデックス、きれいなbinlogの設定で最速の利益を達成します。その後、クエリーの設計、レイテンシーの分析、そしてサプライズのないアップグレードパスが重要です。このロードマップで パフォーマンス 測定可能で信頼できる。.