1. Explain を使用してクエリ プランを表示します。
2. show processlist を使用してクエリ プロセス (状態) を表示します。mysql -uroot -p -e 'show processlist G' |grep state: |sort|uniq -c|sort -rn この方法は方法 3 に似ています。方法 3 の方が便利であると言うべきです。
3. プロフィールを表示するを使用します。 デフォルトでは無効になっており、プロファイリング = 1 を設定して有効にする必要があります。いくつかのクエリを実行した後、show profiles と入力すると、以前に実行されたステートメントのクエリ時間が高精度で表示されることを確認します。次に、show profile for query n を使用して、クエリ ステートメントに対応するクエリ実行の各ステップとそれにかかる時間を確認します。
4. 遅いログを使用し、サードパーティ ツール pt-query-digest で分析レポートを生成します。この分析方法を使用する場合、構成ファイルを変更する必要がある可能性が高く、次の形式に設定できます: log_slow_queries = /var/log/mysql/mysql-slow.log#ログ保存ディレクトリ long_query_time = 0 //すべてのクエリログを取得 -queries-not-using-indexes//インデックスを使用しなくても記録可能
このプロジェクトでは、プログラムの実行時間のほぼすべてがデータベース操作に費やされていることが判明しました。 pt-query-digest を使用して、スロー クエリ ログの分析レポートを作成します (実際の運用では、スロー クエリ ログを開いたり閉じたりするのは簡単ではありません。このとき、TCP トラフィックを監視するか、tcpdump を使用することでシミュレートできます)。更新操作と挿入操作がすべての時間の 95% を占めていることがわかります。
そこで、実行されたステートメントをさらに分析します。
この更新ステートメントの各部分の消費時間は次のとおりです。
主にクエリ終了状態に時間が費やされていることがわかります。
Google から答えを取得し、innodb_flush_log_at_trx_commit = 0 を mysql 設定ファイル my.conf に追加します。 検証の結果、問題は正常に解決され、速度の向上は明らかでした (上記の変更は挿入操作にも影響しました)。 同時に、クエリ終了のステータスはどうなっているのか、なぜこれほど時間がかかるのか、そして innodb_flush_log_at_trx_commit = 0 を追加した後にパフォーマンスが大幅に向上したのはなぜなのかという疑問も残ります。
クエリ終了のステータスは何ですか? mysql の公式ドキュメントでは、次のように説明されています。 この状態は、クエリの処理後、アイテムの解放状態になる前に発生しますが、ステートメントは実行されていますが、まだ完了していないフォローアップ作業がいくつかあります。
では、アイテムの解放状況はどうなっているのでしょうか?スレッドはコマンドを実行しました。この状態中に行われる一部の項目の解放にはクエリ キャッシュが含まれます。これは通常、クエリ キャッシュ内の領域を解放するためのものです (これは更新操作であるため、対応する処理が行われます)。キャッシュ内のレコードは無効であるため、この手順が必要です)。
innodb_flush_log_at_trx_commit のデフォルト値は 1 です。このときの動作は次のとおりです: トランザクションのコミットごとにログ バッファがログ ファイルに書き込まれ、ディスクへのフラッシュ操作がログ ファイルに対して実行されます。ログ バッファの機能: トランザクションは、実行が完了した後にのみディスクにログを書き込むことができます (トランザクションはログを維持する必要があります)。時間は主にディスク IO に費やすべきですか?
innodb_flush_log_at_trx_commit の値を 0 に変更した後の動作は次のようになります: innodb_flush_log_at_trx_commit の値が 0 の場合、ログ バッファーは 1 秒に 1 回ログ ファイルに書き込まれ、ログ ファイルに対してディスクへのフラッシュ操作が実行されます。ただし、トランザクションのコミット時には何も行われません。 0 に変更した後は、毎回実行する必要がある操作が 1 秒に 1 回だけ実行されるようになり、時間を大幅に節約できることがわかります。
innodb_flush_log_at_trx_commit の値を 0 に設定すると副作用があります。サーバー側の mysql プログラムがクラッシュすると、トランザクションの最後の 1 秒が (ログ ファイルに記録される前に) 失われます。しかし、このアプリケーションはトランザクションに関してそれほど厳密な要件を必要としないことを考慮すると、これは許容範囲です。
上記は、mysql ステートメントのパフォーマンス分析と最適化です。その他の関連コンテンツについては、PHP 中国語 Web サイト (www.php.cn) に注目してください。
