テーブルは適切に構築されていますか。 特に、カラムに適切なデータ型があり、各テーブルに、作業の種類に適切なカラムがありますか。 たとえば、頻繁な更新を実行するアプリケーションでは、多くの場合に少数のカラムのある多数のテーブルを使用し、大量のデータを解析するアプリケーションでは、多くの場合に多数のカラムのある少数のテーブルを使用します。

クエリーを効率的にするため、適切なインデックスが設定されていますか。

テーブルごとに適切なストレージエンジンを使用しており、使用している各ストレージエンジンの長所と機能を生かしていますか。 特に、InnoDB などのトランザクションストレージエンジンまたは MyISAM などの非トランザクションストレージエンジンの選択は、パフォーマンスとスケーラビリティーにきわめて重要な場合があります。

各テーブルは適切な行フォーマットを使用していますか。 この選択は、テーブルに使用されるストレージエンジンによっても異なります。 特に、圧縮テーブルは使用するディスク領域が減るため、データの読み取りと書き込みに必要なディスク I/O も少なくなります。 圧縮は、InnoDB テーブルでのあらゆる種類のワークロードと、読み取り専用 MyISAM テーブルに使用できます。

アプリケーションでは、適切なロック戦略を使用していますか。 たとえば、データベース操作を同時に実行できるように、可能なかぎり共有アクセスを許可したり、重要な操作が最優先されるように、適切な場合に排他的アクセスを要求したりするなどです。 ここでも、ストレージエンジンの選択が重要です。 InnoDB ストレージエンジンは、ユーザーが関与せずに、ほとんどのロックの問題を処理するため、データベースの同時実行性を向上し、コードの実験やチューニングの量を削減できます。

キャッシュに使用されるメモリー領域がすべて正しくサイズ設定されていますか。 つまり、頻繁にアクセスされるデータを保持するために十分な大きさがありながらも、物理メモリーをオーバーロードし、ページングを発生させるほど大きくしません。 構成するメインメモリー領域は、InnoDB バッファプールおよび MyISAM キーキャッシュです。

ディスクシーク。 ディスクがデータを検索するには時間がかかります。 最新のディスクでは、通常この平均時間が 10 ms 未満であるため、理論的には 1 秒間に約 100 シーク実行できることになります。 この時間は、新しいディスクでは徐々に改善されますが、1 つのテーブルに対して最適化することはきわめて困難です。 シーク時間を最適化する方法は、複数のディスクにデータを分散することです。

ディスクの読み取りと書き込み。 ディスクが正しい位置にある場合に、データを読み取りまたは書き込みする必要があります。 最新のディスクでは、1 つのディスクで少なくとも 10 - 20M バイト/秒のスループットを実現します。 これは、複数のディスクから並列で読み取ることができるため、シークより最適化が簡単です。

CPU サイクル。 データがメインメモリー内にある場合、結果を得るために、それを処理する必要があります。 メモリーの量と比較して大きなテーブルを使用することは、もっとも一般的な制限要因になります。 しかし、小さいテーブルでは、通常速度は問題になりません。

メモリー帯域幅。 CPU で、CPU キャッシュに収められるより多くのデータを必要とする場合、メインメモリーの帯域幅がボトルネックになります。 これは、ほとんどのシステムでまれなボトルネックですが、認識しておくべきです。