データベースのパフォーマンスは、テーブル、クエリー、構成設定など、データベースレベルの複数の要因に依存します。これらのソフトウェア構造は、ハードウェアレベルでの CPU および I/O 操作につながり、それらを最小限にし、可能なかぎり効率的にする必要があります。データベースのパフォーマンスを行う際は、ソフトウェア側の高レベルのルールとガイドラインについて学び、時計を使ってパフォーマンスを測定することから始めます。熟練するにつれ、内部で起こっていることについて詳しく学習し、CPU サイクルや I/O 操作などの測定を開始します。
一般的なユーザーの目標は、既存のソフトウェアやハードウェア構成から、最高のデータベースパフォーマンスを得ることです。上級ユーザーは、MySQL ソフトウェア自体を改善する機会を見つけたり、独自のストレージエンジンやハードウェアアプライアンスを開発して、MySQL エコシステムを拡張したりします。
データベースレベルでの最適化
データベースアプリケーションを高速にすることにおいてもっとも重要な要素は、その基本設計です。
テーブルは適切に構築されていますか。特に、カラムに適切なデータ型があり、各テーブルに、作業の種類に適切なカラムがありますか。たとえば、頻繁な更新を実行するアプリケーションでは、多くの場合に少数のカラムのある多数のテーブルを使用し、大量のデータを解析するアプリケーションでは、多くの場合に多数のカラムのある少数のテーブルを使用します。
クエリーを効率的にするため、適切なインデックスが設定されていますか。
-
テーブルごとに適切なストレージエンジンを使用しており、使用している各ストレージエンジンの長所と機能を生かしていますか。特に、
InnoDB
などのトランザクションストレージエンジンまたはMyISAM
などの非トランザクションストレージエンジンの選択は、パフォーマンスとスケーラビリティーにきわめて重要な場合があります。注記MySQL 5.5 以上では、
InnoDB
は新しいテーブルのデフォルトのストレージエンジンです。実際に、高度なInnoDB
パフォーマンス機能は、InnoDB
テーブルが、特にビジーなデータベースに対して、多くの場合に単純なMyISAM
テーブルよりパフォーマンスが優れていることを意味します。 各テーブルは適切な行フォーマットを使用していますか。この選択は、テーブルに使用されるストレージエンジンによっても異なります。特に、圧縮テーブルは使用するディスク領域が減るため、データの読み取りと書き込みに必要なディスク I/O も少なくなります。圧縮は、
InnoDB
テーブルでのあらゆる種類のワークロードと、読み取り専用MyISAM
テーブルに使用できます。アプリケーションでは、適切なロック戦略を使用していますか。たとえば、データベース操作を同時に実行できるように、可能なかぎり共有アクセスを許可したり、重要な操作が最優先されるように、適切な場合に排他的アクセスを要求したりするなどです。ここでも、ストレージエンジンの選択が重要です。
InnoDB
ストレージエンジンは、ユーザーが関与せずに、ほとんどのロックの問題を処理するため、データベースの同時実行性を向上し、コードの実験やチューニングの量を削減できます。キャッシュに使用されるメモリー領域がすべて正しくサイズ設定されていますか。つまり、頻繁にアクセスされるデータを保持するために十分な大きさがありながらも、物理メモリーをオーバーロードし、ページングを発生させるほど大きくしません。構成する主なメモリー領域は、
InnoDB
バッファープール、MyISAM
キーキャッシュ、MySQL クエリーキャッシュです。
ハードウェアレベルでの最適化
データベースがビジーになるほど、どんなデータベースアプリケーションも最終的にハードウェアの制限に達します。データベース管理者は、アプリケーションをチューニングするか、サーバーを再構成してこれらのボトルネックを回避できるかどうか、または追加のハードウェアリソースが必要かどうかを評価する必要があります。システムボトルネックは一般に次の原因から発生します。
ディスクシーク。ディスクがデータを検索するには時間がかかります。最新のディスクでは、通常この平均時間が 10 ms 未満であるため、理論的には 1 秒間に約 100 シーク実行できることになります。この時間は、新しいディスクでは徐々に改善されますが、1 つのテーブルに対して最適化することはきわめて困難です。シーク時間を最適化する方法は、複数のディスクにデータを分散することです。
ディスクの読み取りと書き込み。ディスクが正しい位置にある場合に、データを読み取りまたは書き込みする必要があります。最新のディスクでは、1 つのディスクで少なくとも 10 - 20M バイト/秒のスループットを実現します。これは、複数のディスクから並列で読み取ることができるため、シークより最適化が簡単です。
CPU サイクル。データがメインメモリー内にある場合、結果を得るために、それを処理する必要があります。メモリーの量と比較して大きなテーブルを使用することは、もっとも一般的な制限要因になります。しかし、小さいテーブルでは、通常速度は問題になりません。
メモリー帯域幅。CPU で、CPU キャッシュに収められるより多くのデータを必要とする場合、メインメモリーの帯域幅がボトルネックになります。これは、ほとんどのシステムでまれなボトルネックですが、認識しておくべきです。
移植性とパフォーマンスのバランス
ポータブル MySQL プログラムで、パフォーマンス指向の SQL 拡張を使用するには、ステートメント内の MySQL 固有のキーワードを /*! */
コメント区切り文字で囲むことができます。ほかの SQL サーバーはコメントにされたキーワードを無視します。コメントの作成については、セクション9.6「コメントの構文」を参照してください。