MySQL データベースのパフォーマンス最適化の概要

なぜ最適化するのですか? ?

データ量が多すぎるため、プロジェクトの展開からユーザーの使用まで、データは毎日数十万単位で増加し、サーバーに非常に大きな負担がかかります。インターネットは常に高いパフォーマンスを追求してきましたが、ビジネス規模が大きくなり、ユーザー数が増えるにつれて、サーバーのパフォーマンスはますます悪化するため、データベースに対する要件は高くする必要があります。

どこから始めますか? ?

まず、クエリ速度です。データ量が TB レベルに達した場合でも、数百万のクエリ速度を達成できると期待しています。

2 つ目は同時実行性です。数千、数万の同時アクセスを同時に処理でき、Redis、MQ などと連携できる必要があります。

3 つ目は、高可用性です。ビジネス規模が拡大するにつれて、数十台から数百台、さらには数千台にまでサーバーをいつでも拡張できるように準備しておく必要があるため、MySQL クラスターを装備する必要があります。

4 番目は、トランザクション セキュリティです。ビジネスで同時アクセスが多く発生した場合、読み取りと書き込みの一貫性をどのように確保すればよいでしょうか。 ? ?取引のセキュリティを確保しますか? ? ? マルチスレッドの考え方を参考にしてください。 。

解決策は何ですか? ? ?

最初に考えるべきことは、どのようなストレージ エンジンを使用するかということです。ストレージ エンジンによってパフォーマンスが決まるからです。車、飛行機、戦車のどれを使用するかと同じように、各エンジンには特別な機能があります。 ビジネスでよく使われるものは、INNODB と MYISAM の 2 つです。

どうやって選ぶ？ ? ?

ビジネス上の読み取りおよび書き込み要件がそれほど多くなく、主にクエリを使用する場合は、MyISAM を使用します。トランザクションの整合性、同時実行性、頻繁な追加と削除、および頻繁な読み取りおよび書き込み操作に対する要件が高い場合は、INNODB を使用する方が適しています。

次に、クエリを高速化する必要があるため、テーブルの特別なフィールドにインデックスを追加する必要があります。インデックスの原則は、データのストレージ構造を変更することです。ここでは 2 つのタイプがあります。1 つ目は BTree、2 つ目は B+Tree です。 私たちのビジネスでは、一般的に B+Tree を使用しています。BTree の特徴の 1 つは、ルート ノードとリーフ ノードの両方にデータが格納されることです。これにより、たとえば最下位のリーフ ノードをクエリし、ルート ノードのデータをレイヤーごとに読み取ることになりますが、ディスク I/O 回数が増加し、データベースへの負荷が目に見えないほど増加します。 そこでB+ツリーを使う必要がある

3 番目に、高可用性ソリューションを実装します。ここでは、読み取りと書き込みの負荷を軽減するために、データベース サービスにマスター スレーブ構造のクラスターを装備します。

4 番目はセキュリティの問題です。ここでは、高同時アクセスを解決する方法など、スレッド セキュリティの問題を参照できます。 ?取引の整合性をどのように確保できますか? ? RocketMQ と同様に、トランザクション メッセージも関係します。このような問題を回避するにはどうすればよいでしょうか? ロックすることができます。 ロックの分類は以下の通りです。

SQL 最適化

1. クエリを実行するときにテーブル全体のスキャンを避けます。まず、where フィールドと order by フィールドにインデックスを追加することを検討します。

2. whereフィールドでNULL値を使用することは避けてください。テーブルを設計するときはNOT NULL制約を使用するようにしてください。一部のデータはデフォルトでNULLになり、デフォルト値を0または-1に設定できます。

3. where 句では != または <> 演算子を使用しないでください。MySQL は、<、<=、=、>、>=、BETWEEN、IN、および場合によっては LIKE に対してのみインデックスを使用します。

4. ORを使用して条件を接続することは避けてください。そうしないと、エンジンがインデックスを放棄してテーブル全体をスキャンする可能性があります。結合されたクエリにはUNIONを使用できます。

num = 30 の場合、t から id を選択 union num = 40 の場合、t から id を選択;

5. where句では関数や式の操作を避ける

6. select * from t を使用しないことをお勧めします。「*」を特定のフィールド リストに置き換え、未使用のフィールドを返さないようにしてください。

7. in は in ではなく、慎重に使用してください。そうしないと、次のような完全なテーブルスキャンが発生します。

select id from t where num IN(1,2,3) 値が連続している場合は、between および、select id from t where between 1 and 3 を使用することをお勧めします。

8. select id from t where col like %a%; ファジークエリの左側の%は、テーブル全体の検索になります。全文検索が必要な場合は、es、slorなどの全文検索エンジンを使用できます。

9. オフセット行を制限する ページング クエリでは、大きなオフセットを避けるようにしてください。たとえば、limit 10000,10 は、最初の 10,000 行を破棄して、10 行を取得することと同じです。フィルター処理 (スクリーニングの完了) にいくつかの条件を追加できますが、クエリされたデータをスキップするために limit を使用しないでください。これは、==offset が無駄な作業を行っている== という問題です。実際のプロジェクトでは、大きなページ番号を避け、条件によってフィルタリングするようにユーザーを誘導する必要があります。

要約する

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