この記事では、mysql に関する関連知識を提供します。主に、PHP アプリケーションのパフォーマンスを大幅に最適化するためのインデックス作成に関する関連コンテンツを紹介します。一緒に見ていきましょう。皆様のお役に立てれば幸いです。
私の友人は 2 か月前にプロジェクトを行う予定で、オンラインでの迅速なプロモーションを目的として、直接企業のソースコードを購入し、販売者にオンラインで展開させました。ソースコードを見た後、私は友人に「騙されました。このソースコードの品質は少し悪く、ユーザー数が増えると重大なパフォーマンスの問題が発生する可能性があります。」と直接言いました。
私にはそのような評価を行うための根拠があります:
準リアルタイム アプリケーションとして、コア コードは PHP で書かれており、多数のコードの同時実行性が実現されています。シナリオはデータベース テーブル レコードによって制御され、繰り返しのリクエスト;
PHP 開発は問題ありませんが、他のエンジニアは CLI モードがあることを知らなかったようですが、スケジュールされたモードを使用していますプログラムのノンストップ実行を実現するためのタスク (crontab) は膨大であるため、毎分数十のカールスケジュールされたタスクが実行されます;
class1.php と class1- が多数あります。 1.phpファイルがコード内に存在します 一見しただけでは存在が分かりにくいです 目的;
データベースを読み込むためのループコードや命名規則が多いです混乱しています。
もちろん、儲かるコードは良いコード(相手はそのコードで儲かっている)なので、あまり気にしません。当初は、4 コア 8G 構成では 10,000 人の顧客にサービスを提供するのは難しいが、5,000 人あれば十分であると考えられていました。
今週、突然、Alibaba Cloud から CPU 使用率が高すぎるというアラーム テキスト メッセージや電子メールを頻繁に受け取りました。マーケティングプロモーションはうまくいき、ユーザー数は大幅に増加したと思いますか?友達に聞いたらユーザーは300人もいなかった!
#この時点で、このコードの実際のパフォーマンスは思ったよりも悪く、パフォーマンスに重大な問題があることに気付きました。このリソース消費率によると、ハードウェアのアップグレードは底なし沼であり、パフォーマンスの最適化が正しい方法であることがわかります。
コードを入手してから 2 か月が経ちましたが、暇なときに時々眺めており、すでにその構造と主な機能については大体理解しています。深刻なパフォーマンスの問題が発生したので、パフォーマンスの最適化を試してみましょう。
数十のスケジュールされたタスクが継続的に実行され、システム動作を継続的に駆動するという事実を考慮すると、スケジュールされたタスクの関連機能が最初に理解される必要があります。私自身の理解に基づいて、まず、不要になった 20 以上の予定されていたタスクを一時停止しました。無駄なスケジュールされたタスクを一時停止すると、システム全体の CPU 使用率が 60% 以上に低下し、迷惑なリマインダーのテキスト メッセージや電子メールがついに止まりました。 1 日待っても、友人からは機能が影響を受けたという報告はありませんでした。これは、このアイデアと出発点が正しかったことを示しています。
しかし、200 人を超えるユーザーがこのようにリソースを消費しているのですから、何か問題があるはずです。今日暇なときにサーバーに再度ログインし、top コマンドを実行したところ、mysql プロセスが CPU リソースの 200% 以上を占有していることがわかりました。ソース コードを読んだ後、MySQL の使用率が高いのには理由があり、それが可能であることはわかりましたが、なぜこれほど多くのリソースを消費するのかを知りたいと思っています。
MySQL サーバーにログインし、スロー ログが有効かどうかを確認します: '%slow%' のような変数を表示し、スロー クエリ ログが有効であることを確認します:
続行 ログを確認すると、特定の SQL ステートメントが常にログに表示されていることがわかります。
##380,000 行を超えるレコードがスキャンされたことがわかります。この SQL ステートメントが実行されたとき。ステートメントに含まれる 2 つのテーブルのうち 1 つは 600 を超えるレコードを持ち、もう 1 つは 40,000 を超えるレコードを持ちます。これは、40,000 を超えるレコードを持つテーブル全体を数回スキャンすることに相当します。非常に遅いのも不思議ではありません。 次に、2 つのテーブルのインデックスを確認します。主キーとして自動インクリメントされる ID を除いて、他のインデックスは作成されません。 Explain を使用してステートメントを実行すると、インデックスが使用されていないことがわかります。 次に、2 つのテーブルのクエリ条件の uid 列と session_id 列にインデックスを作成します。インデックスの作成が完了すると、目に見える CPU 使用率とシステム負荷が軽減されます。クエリ ステートメントを実行するには、もう一度 Explain を使用します。インデックス情報が使用され、スキャンされる行の数が大幅に減少しました: 上記の最適化後、現在の全体的な CPUアプリケーションの使用率は 5% 15% 付近で、MySQL の CPU 使用率は 4 から 0.3 に低下しました。最後に、当面はパフォーマンスの問題を心配する必要はなく、サーバー構成が 1 コア CPU に削減された場合でも、引き続き維持できます。 コードをさらに確認し、ログと組み合わせてインデックスを作成し、いくつかのクエリ ステートメントを変更します。CPU 使用率は約 6% に低下しました。最終的に、当面はパフォーマンスの問題を心配する必要はありません開発プロジェクトでは、エンジニアは「使える」コードだけでなく「使いやすい」コードも書く必要があります。この例では、2 つのインデックスを作成することにより、システムのパフォーマンスが大幅に向上し、コードが「使いやすい」から「使いやすい」に変わります。
この記事で説明するパフォーマンスの最適化は運用と保守に重点を置いており、コード内のパフォーマンスの最適化にはまだ触れていません。ただし、一般原則は正しいです。つまり、より多くのキャッシュを使用し、低速 IO デバイスからの同期読み取りをできるだけ減らすということです。
推奨学習: 「mysql ビデオ チュートリアル 」、「PHP ビデオ チュートリアル 」
以上がMySQL インデックスを作成して PHP アプリケーションのパフォーマンスを大幅に最適化するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。