アプリケーションが関連する更新を実行するために複数のデータベースリクエストを作成する場合、ステートメントをストアドルーチンに結合するとパフォーマンスが向上します。 同様に、アプリケーションで複数のカラム値または大量のデータに基づいて単一の結果を計算する場合、計算を UDF (ユーザー定義関数) に結合するとパフォーマンスが向上します。 結果の高速データベース操作は、他のクエリー、アプリケーションおよび異なるプログラミング言語で記述されたコードで再利用できます。 詳細は、セクション25.2「ストアドルーチンの使用」 および Adding Functions to MySQL を参照してください。

ARCHIVE テーブルで発生する圧縮の問題を修正するには、OPTIMIZE TABLE を使用します。 セクション16.5「ARCHIVE ストレージエンジン」を参照してください。

可能な場合は、レポートを「「ライブ」」または「「統計」」として分類します。統計レポートに必要なデータは、ライブデータから定期的に生成されるサマリーテーブルからのみ作成されます。

行とカラムのテーブル構造に適合しないデータがある場合は、データを圧縮して BLOB カラムに格納できます。 この場合、情報を圧縮および解凍するためのコードをアプリケーションに指定する必要がありますが、これにより、関連する値のセットの読取りおよび書込みのための I/O 操作が保存される可能性があります。

Web サーバーでは、イメージおよびその他のバイナリアセットをファイルとして格納し、パス名をファイル自体ではなくデータベースに格納します。 ほとんどの Web サーバーは、データベースコンテンツよりファイルのキャッシュに優れているため、ファイルの使用は一般に高速です。 (ただし、この場合はバックアップとストレージの問題を自分で処理する必要があります。)

実際に高速化が必要な場合は、低レベルの MySQL インタフェースを参照してください。 たとえば、MySQL InnoDB または MyISAM ストレージエンジンに直接アクセスすると、SQL インタフェースを使用する場合と比べて大幅に高速化できます。

同様に、NDBCLUSTER ストレージエンジンを使用するデータベースの場合は、NDB API の使用可能な使用状況を調査することをお勧めします (MySQL NDB Cluster API Developer Guide を参照)。

レプリケーションは、特定の操作でパフォーマンスの向上を実現できます。 クライアントの取得をレプリカ間で分散して、負荷を分割できます。 バックアップの作成中にソースの速度が低下しないように、レプリカを使用してバックアップを作成できます。 第17章「レプリケーション」を参照してください。