この記事の内容は、mysql の最適化に関する概要です。必要な方は参考にしていただければ幸いです。
まえがき
現在、特に Web アプリケーションでは、データベース操作がアプリケーション全体のパフォーマンスのボトルネックになっています。したがって、MySQL の最適化に関するいくつかの提案をまとめました。まとめられない場合は、ぜひ追加してください。
SQL 実行が遅い理由
ネットワーク速度の遅さ、メモリ不足、I/O スループットの低下、ディスク容量の不足、その他のハードウェアの問題
インデックスなしまたはインデックスの失敗
-
##サーバーのチューニングとさまざまなパラメーターの設定
その他
EXPLAIN によって記述された SQL の効率にも影響する可能性があります。 SELECT クエリを分析する
2. SELECT クエリではフィールド名を指定する必要があります。
SELECT * クエリでは、同時に多くの不要な消費が発生します (CPU、I/O など)。 、カバリングインデックスの使用も増加する可能性があります。したがって、SELECTクエリを実行する場合は、最後にクエリ対象となる対応するフィールド名を直接指定する必要があります。
3. データの一部をクエリするときは、LIMIT 1
を使用して冗長なクエリを減らします。これは、制限 1 を指定すると、データの一部をクエリした後にクエリが続行されなくなり、 EXPLAIN の type 列 const 型に到達するには、クエリ ステートメントの方が適しています。
4. 検索された WHERE フィールドのインデックスを作成します
通常、テーブルごとに主キーを設定しますが、インデックスは必ずしも主キーである必要はありません。テーブル内に WHERE クエリと検索に常に使用するフィールドがあり、書き込みよりも読み取りの方が多い場合は、そのフィールドのインデックスを作成してください。インデックス作成の原則について詳しく知りたい場合は、「関連情報」を参照してください。見つけられた。
5. ORDER BY RAND() は絶対に使用しないでください。
データをランダムに取得したい場合は、最初のメソッドで乱数を使用するように直接指示されるかもしれません。この時点では Control を使用する必要があることを覚えておいてください。あなたの脳がこの方向に思考を続け、この恐ろしい考えを止めます。この種のクエリはデータベースのパフォーマンスに何のメリットもない (CPU を消費する) ためです。より良い解決策の 1 つは、最初にデータの数 N を見つけてから、
LIMIT N, 1
を使用してこのようにクエリを実行することです。
6. 各テーブルに主キー ID があることを確認する
8. できる限り NOT NULL を使用します。
NULL にはスペースが必要ないと考えないでください。おそらく、多くの人は気づいていませんが、NULL にも余分なスペースが必要です。 NULL フィールドが存在する場合、クエリと比較を行うとさらに面倒になります。もちろん、本当に NULL が必要な場合は問題なく使用できます。それ以外の場合は、NOT NULL を使用することをお勧めします。
8. 適切なストレージ エンジンを選択する
MySQL には MyISAM と InnoDB という 2 つのストレージ エンジンがあり、どちらにも独自の長所と短所があるため、2 つの違いを理解する必要があります。適切な選択を行ってください。たとえば、InnoDB はトランザクションをサポートしますが、MyISAM はサポートしません。MyISAM クエリは InnoDB よりも高速です。つまり、何を選択すればよいかわからない場合は、InnoDB を使用してください。
9. IP アドレスを UNSIGNED INT として保存する
IP アドレスを保存する必要がある場合、多くの人は最初に VARCHAR (15) 文字列タイプを保存することを考えるでしょう。 INT 整数型を使用して格納することは考えられません。整数型を使用して格納すれば、必要なバイト数は 4 バイトだけであり、固定長フィールドを使用できるため、クエリに利点が得られます。
10. WHERE クエリ中にフィールドの null 値を判断しないようにしてください
フィールドを null と判断すると、これが原因で速度が低下することは誰もが知っています。この判断により、エンジンは既存のすべてのインデックスの使用を放棄し、フル テーブル スキャン検索を実行します。
11. % プレフィックス付きの LIKE ファジー クエリは使用しないようにしてください。
ファジー クエリは日常の開発で頻繁に遭遇しますが、多くの人は直接
LIKE ' %key_word%' を使用すると思います。
または
LIKE '%key_word'
はこのように検索されます。これらの 2 つの検索方法ではインデックスが失敗し、フル テーブル スキャン検索が必要になります。上記のあいまいなクエリを解決したい場合、答えは「全文インデックスを使用する」です。具体的な使用方法に興味がある場合は、自分で情報を確認してください。
SELECT id FROM table WHERE num * 2 = 50;
などのクエリです。フィールド num に 2 を掛ける算術演算を実行すると、インデックスが失敗します。
14. 不必要なソートを減らす
ソート操作はより多くの CPU リソースを消費するため、キャッシュ ヒット率が高く、I/O 時間が十分である場合、不必要なソートを減らすと SQL パフォーマンスが低下する可能性があります。
14. サブクエリの代わりに JOIN を使用することをお勧めします。
JOIN のパフォーマンスはそれほど良くないという人もいますが、それでもサブクエリと比較するとパフォーマンスに大きな利点があります。具体的には、サブクエリの実行計画に関連する問題について学ぶことができます。
15. 暗黙的な型変換を避ける
型変換とは、主に、WHERE 句のフィールドの型が、渡されるパラメータの型と一致しない場合に発生する型変換を指します。渡したデータ型がフィールド型と一致しない場合、MySQL は渡したデータに対して型変換操作を実行するか、データを処理せずにストレージ エンジンに直接渡して処理する可能性があるためです。使用状況によっては、実行計画の問題が発生する可能性があります。
16. 複数テーブルのクエリで一貫性のないフィールド タイプを回避する
複数テーブルの結合クエリが必要になった場合は、テーブル構造を設計するときに、そのクエリに関連付けられたフィールドを維持するようにしてください。テーブルはテーブルと一致しており、インデックスを設定する必要があります。同時に、複数テーブル接続クエリを実行する場合は、結果セットが小さいテーブルを駆動テーブルとして使用するようにしてください。
17. クエリ キャッシュをオンにすることをお勧めします。
ほとんどの MySQL サーバーではクエリ キャッシュがオンになっているため、これはパフォーマンスを向上させる最も効果的な方法の 1 つです。同じクエリの多くが複数回実行されると、これらのクエリ結果はキャッシュに保存されるため、後続の同一のクエリはテーブルを操作する必要がなく、キャッシュされた結果に直接アクセスします。
18. 一時テーブルの代わりに UNION を使用する
UNION クエリは 2 つ以上の SELECT クエリの結果を 1 つのクエリにマージできるため、完了のために一時テーブルを作成する必要はありません。 UNION を使用するすべての SELECT ステートメント内のフィールドの数は同じである必要があることに注意してください。
19. IN クエリは注意して使用してください
IN クエリと NOT IN クエリはテーブル全体のスキャンにつながる可能性があるため、使用できる場合は使用しないでください。間。
20. 追加へようこそ。
結論
これは、主にクエリ、一部のサブテーブル、パーティション テクノロジ、および読み取り/書き込みの観点から最適化を検討するためのものです。分離; 上記の最適化 上記の点が適切でない場合は、MySQL を最適化できる箇所がたくさんあることをご理解ください。
以上が20 mysqlの最適化まとめの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
