Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 26.8Mb
PDF (A4) - 26.9Mb
HTML Download (TGZ) - 7.1Mb
HTML Download (Zip) - 7.2Mb


8.1 最適化の概要

データベースのパフォーマンスは、テーブル、クエリー、構成設定など、データベースレベルの複数の要因に依存します。これらのソフトウェア構造は、ハードウェアレベルでの 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「コメントの構文」を参照してください。


User Comments
User comments in this section are, as the name implies, provided by MySQL users. The MySQL documentation team is not responsible for, nor do they endorse, any of the information provided here.
Sign Up Login You must be logged in to post a comment.