MySQLの長時間実行クエリの処理

MySQL環境では、長時間実行されるクエリ/ステートメント/トランザクションが避けられない場合があります。場合によっては、長時間実行されるクエリが悲惨なイベントのきっかけになることがあります。データベースに関心がある場合は、クエリパフォーマンスの最適化と、長時間実行されるクエリの検出を定期的に実行する必要があります。ただし、グループまたはクラスター内の複数のインスタンスが関係している場合は、事態はさらに困難になります。

複数のノードを処理する場合、すべてのノードをチェックするための反復的なタスクは避けなければなりません。 ClusterControlは、クエリを含むデータベースサーバーの複数の側面を監視します。 ClusterControlは、グループまたはクラスター内のすべてのノードからのすべてのクエリ関連情報を集約して、ワークロードの集中ビューを提供します。最小限の労力でクラスター全体を理解するための優れた方法があります。

このブログ投稿では、ClusterControlを使用してMySQLの長時間実行クエリを検出する方法を紹介します。

クエリに時間がかかるのはなぜですか？

まず、クエリの性質を知る必要があります。これは、長時間実行されるクエリであるか、短期間のクエリであると予想されるかです。一部の分析およびバッチ操作は長時間実行されるクエリであると想定されているため、ここではそれらをスキップできます。また、テーブルのサイズによっては、ALTERコマンドを使用してテーブル構造を変更すると、長時間実行される操作になる可能性があります。

短期間のトランザクションの場合、通常は1秒未満で、可能な限り高速に実行する必要があります。短いほど良いです。これには、WHEREまたはJOINステートメントで適切なインデックスを使用する、適切なストレージエンジンを使用する、適切なデータ型を選択する、オフピーク時にバッチ操作をスケジュールする、分析をオフロードするなど、ユーザーが従う必要のある一連のクエリのベストプラクティスルールが付属しています。 /専用レプリカへのトラフィックの報告など。

クエリの実行に時間がかかる原因となる可能性のあるものがいくつかあります。

非効率的なクエリ-ルックアップまたは結合中にインデックス付けされていない列を使用するため、MySQLが条件を一致させるのに時間がかかります。
テーブルロック-クエリがテーブルにアクセスしようとすると、グローバルロックまたは明示的なテーブルロックによってテーブルがロックされます。
デッドロック-クエリは、別のクエリによってロックされている同じ行にアクセスするのを待機しています。
データセットがRAMに収まらない-ワーキングセットデータがそのキャッシュに収まる場合、SELECTクエリは通常比較的高速になります。
次善のハードウェアリソース-これは、低速のディスク、RAIDの再構築、飽和状態のネットワークなどである可能性があります。
メンテナンス操作-mysqldumpを実行すると、大量の未使用のデータがバッファプールに取り込まれる可能性があります。同時に、すでに存在する（潜在的に有用な）データが削除され、ディスクにフラッシュされます。

上記のリストは、あらゆる種類の問題を引き起こすのはクエリ自体だけではないことを強調しています。 MySQLサーバーのさまざまな側面を検討する必要がある理由はたくさんあります。いくつかの最悪のシナリオでは、クエリが長時間実行されると、サーバーのダウン、サーバーのクラッシュ、接続の最大化など、サービス全体が中断する可能性があります。クエリの実行に通常よりも時間がかかる場合は、調査してください。

確認方法

プロセスリスト

MySQLには、長時間実行されるトランザクションをチェックするための多数の組み込みツールが用意されています。まず、SHOWPROCESSLISTまたはSHOWFULL PROCESSLISTコマンドは、実行中のクエリをリアルタイムで公開できます。これは、SHOW FULL PROCESSLISTコマンドに似たClusterControlの実行中のクエリ機能のスクリーンショットです（ただし、ClusterControlは、クラスター内のすべてのノードのすべてのプロセスを1つのビューに集約します）：

ご覧のとおり、出力からすぐに不快なクエリを確認できます。しかし、どのくらいの頻度でそれらのプロセスを見つめますか？これは、長時間実行されるトランザクションを認識している場合にのみ役立ちます。そうしないと、接続が山積みになったり、サーバーが通常より遅くなったりするなど、何かが発生するまでわかりません。

遅いクエリログ

遅いクエリログは遅いクエリ（ long_query_time 以上かかるSQLステートメント）をキャプチャします実行秒数）、またはルックアップにインデックスを使用しないクエリ（ log_queries_not_using_indexes ）。この機能はデフォルトでは有効になっておらず、有効にするには、次の行を設定してMySQLサーバーを再起動するだけです。

[mysqld]
slow_query_log=1
long_query_time=0.1
log_queries_not_using_indexes=1

遅いクエリログは、実行に時間がかかり、したがって最適化の候補となるクエリを見つけるために使用できます。ただし、長くて遅いクエリログを調べることは、時間のかかる作業になる可能性があります。 MySQLの低速クエリログファイルを解析し、mysqldumpslow、pt-query-digest、ClusterControlトップクエリなどの内容を要約するツールがあります。

ClusterControl Top Queriesは、MySQLの低速クエリログまたはパフォーマンススキーマの2つの方法を使用して低速クエリを要約します。

いくつかの基準に基づいてソートされた、正規化されたステートメントダイジェストの要約を簡単に確認できます。

ホスト
発生
合計実行時間
最大実行時間
平均実行時間
標準偏差時間

この機能については、このブログ投稿「MySQL、MariaDB、およびPerconaサーバー用のClusterControlクエリモニターの使用方法」で詳しく説明しています。

パフォーマンススキーマ

パフォーマンススキーマは、MySQLサーバーの内部と実行の詳細を下位レベルで監視するために利用できる優れたツールです。パフォーマンススキーマの次の表を使用して、遅いクエリを見つけることができます。

events_statements_current
events_statements_history
events_statements_history_long
events_statements_summary_by_digest
events_statements_summary_by_user_by_event_name
events_statements_summary_by_host_by_event_name

MySQL 5.7.7以降には、パフォーマンススキーマによって収集されたデータをDBAと開発者がより理解しやすい形式に解釈するのに役立つオブジェクトのセットであるsysスキーマが含まれています。 Sysスキーマオブジェクトは、一般的なチューニングと診断のユースケースに使用できます。

ClusterControlはアドバイザーを提供します。アドバイザーは、ClusterControl DSL（JavaScriptと同様）を使用して作成できるミニプログラムであり、必要に応じてClusterControl監視機能を拡張できます。パフォーマンススキーマに基づいて含まれているスクリプトがいくつかあり、I / O待機、ロック待機時間などのクエリパフォーマンスを監視するために使用できます。たとえば、管理->デベロッパースタジオ 、 s9s-> mysql-> p_s-> top_tables_by_iowait.jsに移動します「コンパイルして実行」ボタンをクリックします。サーバーごとのI/O待機でソートされた上位10個のテーブルの[メッセージ]タブに出力が表示されます。

top_tables_by_lockwait.js のように、低速が発生する場所と理由を理解するために使用できるスクリプトがいくつかあります。、 top_accessed_db_files.js など。

ClusterControl-長時間実行されるクエリの検出とアラート

ClusterControlを使用すると、標準のMySQLインストールにはない追加の強力な機能を利用できます。 ClusterControlは、実行中のプロセスをプロアクティブに監視し、長いクエリしきい値を超えた場合にアラームを発生させてユーザーに通知を送信するように構成できます。これは、[設定]の[ランタイム構成]を使用して構成できます：

1.7.1より前の場合、 query_monitor_alert_long_running_queryのデフォルト値は偽です。 1（true）に設定して、これを有効にすることをお勧めします。永続的にするには、次の行を/etc/cmon.d/cmon_X.cnfに追加します。

query_monitor_alert_long_running_query=1
query_monitor_long_running_query_ms=30000

ランタイム構成で行われた変更はすぐに適用され、再起動は必要ありません。クエリが30000ms（30秒）のしきい値を超えると、[アラーム]セクションに次のようなメッセージが表示されます。

メール受信者の設定をDbComponentplusCRITICAL重大度カテゴリの「配信」として構成した場合（次のスクリーンショットを参照）：

このアラームのコピーをメールで受け取る必要があります。それ以外の場合は、[メールを送信]ボタンをクリックして手動で転送できます。

さらに、正規表現（regex）を使用して、特定の基準に一致するあらゆる種類のプロセスリストリソースを除外できます。たとえば、ClusterControlで「sbtest」、「myshop」、「db_user1」という3人のMySQLユーザーの長時間実行クエリを検出する場合は、次のようにする必要があります。

ランタイム構成で行われた変更はすぐに適用され、再起動は必要ありません。

さらに、ClusterControlは、パフォーマンス->トランザクションログで発生したときに、すべてのデッドロックトランザクションをInnoDBステータスとともに一覧表示します。：

デッドロックの検出はデータベースノードのCPU使用率に影響するため、この機能はデフォルトでは有効になっていません。有効にするには、[トランザクションログを有効にする]チェックボックスをオンにして、必要な間隔を指定します。永続的にするには、/ etc / cmon.d / cmon_X.cnf内に秒単位の値を持つ変数を追加します：

db_deadlock_check_interval=30

同様に、InnoDBステータスを確認する場合は、パフォーマンス->InnoDBステータスに移動します。、ドロップダウンからMySQLサーバーを選択します。例：

必要な情報はすべて、数回クリックするだけで簡単に取得できます。

概要

トランザクションが長時間実行されると、パフォーマンスの低下、サーバーのダウン、接続の最大化、デッドロックが発生する可能性があります。 ClusterControlを使用すると、クラスター内のすべてのMySQLノードを調べる必要なしに、UIから直接長時間実行されるクエリを検出できます。