データベース構造の最適化

データサイズの最適化

→ ディスクに書き込むデータとディスクから読み取るデータの量を削減します

→ クエリの実行中にコンテンツがアクティブに処理されるため、メイン メモリが減少します

→ インデックスが小さくなり、高速に処理できるようになります

テーブルの列

• 可能な限り最も効率的な (最小の) データ型を使用します
• 可能であれば列を NOT NULL として宣言します → インデックスをより適切に使用し、各値が NULL かどうかをテストするオーバーヘッドを排除します。

インデックス

• テーブルのプライマリ インデックスはできるだけ短くする必要があります
• クエリのパフォーマンスを向上させるために必要なインデックスのみを作成します。インデックスは取得には適していますが、挿入および更新操作は遅くなります。
• 列の組み合わせで検索 → 複合インデックスを作成
• インデックスの最初の列は、重複が最も多い列である必要があります → インデックスの圧縮率を高めるためです。

結合

• 同じデータ型を持つ異なるテーブルで同じ情報を持つ列を宣言 → 同じデータ型
• 列名は単純にしてください。

正規化

• 通常、すべてのデータは冗長性を持たないようにしてください
• ディスク容量やデータのコピーを複数保持するメンテナンスコストよりも速度が重要な場合

データ型の最適化

• 文字列または数値として表現できる一意の ID またはその他の値の場合、 → 数値は、対応する文字列よりも少ないバイト数で保存でき、転送と比較にかかる時間が速くなり、必要なメモリも少なくなります。
• 異なる列の値を比較する場合は、可能な限り同じ文字セットと照合順序でそれらの列を宣言します → 文字列変換を回避します
• サイズが 8KB 未満の列値の場合は、BLOB の代わりにバイナリの VARCHAR を使用します。 GROUP BY 句と ORDER BY 句は一時テーブルを生成できます。元のテーブルに BLOB 列が含まれていない場合、これらの一時テーブルは MEMORY ストレージ エンジンを使用できます。
• テーブルに文字列カラムが含まれており、頻繁にアクセスしない場合 → 別のテーブルに分割して結合 → MySQL が行から値を取得するとき、その行のすべてのカラム (および場合によっては他の隣接する行) を含むデータ ブロックを読み取ります。各行を小さく保ち、最も頻繁に使用される列のみを含めると、より多くの行を各データ ブロックに収めることができます。
• ランダムに生成された値を InnoDB テーブルの主キーとして使用する場合は、可能であれば現在の日付と時刻などの昇順の値を先頭に付けます。
• 複数の列があるテーブルの場合、BLOB 列を使用しないクエリのメモリ要件を軽減するには、BLOB 列を別のテーブルに分割し、必要に応じて結合クエリで参照することを検討してください。
• • BLOB 値を取得および表示するためのパフォーマンス要件は他のデータ型とは大きく異なる可能性があるため、BLOB 固有のテーブルを別のストレージ デバイスまたは 別のストレージ デバイスに配置することもできます。データベース インスタンス。たとえば、BLOB を取得するには、SSD デバイスよりも従来のハード ドライブに適した大規模なシーケンシャル ディスク読み取りが必要になる場合があります。
• 非常に長いテキスト文字列に対して等価性をテストするのではなく、列値のハッシュを別の列に保存し、その列にインデックスを付けて、クエリでハッシュ値をテストできます。 (ハッシュ値を生成するには、MD5() または CRC32() 関数を使用します。)

SQL ステートメントの最適化

パフォーマンスの悪いクエリを 2 つのステップで分析すると便利であることがわかりました:

• アプリケーションが必要以上のデータを取得していないかどうかを確認します。これは通常、アクセスする行が多すぎることを意味しますが、アクセスする列が多すぎることもあります。
• MySQL サーバー が必要以上の行を分析していないかどうかを確認します。

SELECT ステートメントの最適化

• 述語での関数の使用を避ける
• 述語の先頭でワイルドカード (%) を使用しないでください
• 必要な場合にのみ DISTINCT と UNION を使用してください