MySQL パフォーマンス最適化のヒント

MySQL パフォーマンスの最適化

MySQL はインターネット企業で広く使用されており、MySQL のパフォーマンス最適化のニーズがよくあります。 MySQL の最適化に関する実用的なヒントをいくつかまとめました。

スキーマとデータ型の最適化

1. 整数は高速でAUTO_INCREMENTを使用できることから、通常、ID列には最適な選択肢です。
2. 完全に「ランダム」な文字列（ MD5() 、 SHA1() 、またはUUID()によって生成される文字列など）は、大きなスペースにランダムに分散されるため、 INSERTおよび一部のSELECTステートメントが非常に遅くなります。
3. クエリを迅速かつ適切に並行して実行したい場合は、単一のクエリであまり多くの関連クエリを実行せず (インターネット企業は関連クエリを非常に嫌う)、プログラムを使用して関連操作を完了することが最善です。
4. 比較的大きなテーブルのテーブル構造を変更する必要がある場合 ( ALTER TABLE操作で列を追加する場合)、最初に元のテーブルと同じ構造のテーブルをコピーし、次にそのテーブルにデータをコピーし、最後に新しいテーブルの名前を元のテーブルの名前に変更することをお勧めします。テーブル構造を変更すると、テーブル全体がロックされ、長時間使用できなくなる可能性が非常に高くなります。
5. 複数のテーブルの関連付けを回避するには、いくつかの反パラダイム テーブル構築ソリューションを検討し、冗長なフィールドをいくつか追加します。

InnoDB インデックスの最適化

1. インデックスの左端の列から検索を開始しないと、インデックスを使用できません。
2. すべての非クラスター化インデックスでは、まずインデックスを通じて対応する主キーを見つけ、次にクラスター化インデックス内のデータを見つける必要があるため、主キー インデックスを定義するときは注意が必要です。
3. MySQL は、インデックス列の順序がORDER BY句の順序とまったく同じであり、すべての列のソート方向 (逆または順) が同じである場合にのみ、インデックスを使用して結果をソートできます。 ORDER BY句がインデックスの左端のプレフィックス要件を満たす必要がないケースが 1 つあります。つまり、先頭の列が定数である場合です。
4. 文字列フィールドの値を一致させるためにlikeを使用する場合は、 like 'XX%'プレフィックス一致を使用し、 like '%XX'使用は避けてください。
5. ハッシュ インデックスはハッシュ テーブルに基づいて実装されます。インデックスのすべての列に正確に一致するクエリのみが有効であり、インデックスの左端の一致原則には従いません。
6. サーバーが複数のインデックスに対して共同操作を実行する必要がある場合 (通常は複数のOR条件を使用)、インデックスにヒットしやすくなるUNIONモードに変更することをお勧めします。
7. インデックス内の列の順序を選択する方法については、経験則があります。最も選択性の高い列をインデックスの先頭に配置します。
8. 可能な限りカバーインデックスを使用します（インデックスがクエリ対象のすべてのフィールドの値を含むかカバーしている場合、カバーインデックスと呼びます）。EXPLAIN EXPLAIN Extra列に「インデックスの使用」情報が表示されます。
9. IDが主キーの場合、インデックス(A)を作成することは、2つのインデックス(A)と(A, ID)を作成することと同じです。
10. テーブルに含まれるインデックスの数が増えるほど、 SELECT 、 UPDATE 、 DELETE操作が遅くなり、メモリの使用量も増えます。
11. InnoDBはセカンダリインデックスに共有ロックを使用しますが、プライマリキーインデックスにアクセスするには排他ロックが必要です。
12. 可能な場合は常にWHERE INとWHERE BETWEEN AND使用して範囲クエリを実行します。
13. LIMITオフセットが大きいほど、パフォーマンスは低下します。
14. クエリを作成するときは、単一​​行の検索を避け、追加の並べ替え操作を避けるためにデータのネイティブ順序を可能な限り使用し、インデックス カバレッジ クエリを可能な限り使用します。

クエリパフォーマンスの最適化

1. 非効率的なクエリについては、通常、次の 2 つの側面から分析します。

1. アプリケーションが必要以上に大量のデータを取得しているかどうかを判断します。これは通常、アクセスされた行が多すぎることを意味しますが、アクセスされた列が多すぎる場合もあります。
2. MySQLサーバーが必要以上に多くの行を解析していないか確認する
   

2. 一般的に、MySQL では、最良から最悪の順に、次の 3 つの方法を使用して WHERE 条件を適用できます。

• インデックスのWHERE条件を使用して、一致しないレコードを除外します。
• インデックスカバースキャンを使用してレコードを返す
• データテーブルからデータを返し、条件を満たさないレコードを除外します。
  

3.MySQL は、接続と切断を軽量化し、小さなクエリ結果を効率的に返すように設計されています。汎用サーバーでは、1 秒あたり 100,000 件を超えるクエリを実行できます。ギガビット ネットワーク カードでは、1 秒あたり 2,000 件を超えるクエリを簡単に処理できます。MySQL は、1 秒あたり数百万行のデータをメモリ内でスキャンできます。

4. 大量のデータを削除する場合は、少量のデータを削除した後、しばらく待ってから次のデータを削除することをおすすめします。

5. ソートはとにかく非常にコストのかかる操作なので、パフォーマンスの観点から、ソートをできるだけ避けるか、大量のデータのソートをできるだけ避ける必要があります。

6. COUNT() 関数には 2 つの異なる機能があり、列内の値の数または行の数をカウントできます。最も簡単な方法は、COUNT(*)を使用して行数をカウントすることです。

7. 関連クエリを実行するときは、関連フィールドにインデックスがあることを確認してください。

8. データ量が多く、履歴データを定期的に削除する必要がある場合は、パーティションテーブルの使用を検討してください。

9. 指定されたインデックス列とパーティション列が一致しない場合、クエリはパーティションフィルタリングを実行できません。

10. 外部キー制約はできる限り避けてください。通常はプログラミングで実装されますが、外部キーを念頭に置いてください。

11. トリガー、ストアド プロシージャ、カスタム関数などは使用しないことをお勧めします。

12. クエリ キャッシュを可能な限り使用します。クエリ ステートメントの記述時に不確実なデータ (NOW() や CURRENT_DATE() など) がある場合、そのデータはキャッシュされません。

13. 1つの大きなテーブルの代わりに複数の小さなテーブルを使用すると、クエリのキャッシュに適しています。

14. バッチで書き込む場合、キャッシュの無効化は 1 回だけ必要なので、単一書き込み (書き込みが行われるたびにキャッシュが無効化される) よりも効率的です。書き込みが集中するアプリケーションの場合は、クエリ キャッシュを直接無効にします。

15. キャッシュスペースが大きすぎると、有効期限切れ処理中にサーバーがフリーズする可能性があります。

上記は私の仕事での個人的な経験をまとめたものです。説明に誤りがありましたら、ご指摘いただければ幸いです。一緒にコミュニケーションを取り、学んでいきましょう。

これで、MySQL パフォーマンス最適化のヒントを共有するこの記事は終了です。MySQL パフォーマンス最適化に関するより関連性の高いコンテンツについては、123WORDPRESS.COM で以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。