MySQLデータベースのパフォーマンスを提供するためのヒント-パート2-

データベースのパフォーマンスの管理は、管理者が予想よりも多くの時間を費やしていることに気付く場合にビジネスが行う領域です。

本番データベースのパフォーマンスの問題を監視して対応することは、データベース管理者の仕事の中で最も重要なタスクの1つです。これは継続的なプロセスであり、常に注意を払う必要があります。アプリケーションと基盤となるデータベースは通常、時間とともに進化します。サイズ、ユーザー数、ワークロード、コードの変更に伴うスキーマの変更が増加します。

MySQLデータベースでは、実行時間の長いクエリが避けられないことはめったにありません。状況によっては、長時間実行されるクエリが有害なイベントになる場合があります。データベースに関心がある場合は、クエリパフォーマンスの最適化、および実行時間の長いクエリの検出を定期的に実行する必要があります。

このブログでは、特に実行中のクエリ側で、実際のデータベースのワークロードをさらに詳しく見ていきます。クエリを追跡する方法、MySQLメタデータで検出できる情報の種類、そのようなクエリの分析に使用するツールを確認します。

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

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

クエリの実行に通常よりも時間がかかる場合は、調査してください。

MySQLShowプロセスリストの使用

MYSQL> SHOW PROCESSLIST;

これは通常、パフォーマンスの問題が発生した場合に最初に実行するものです。 SHOW PROCESSLISTは、実行中のスレッドを表示する内部mysqlコマンドです。この情報は、information_schema.PROCESSLISTテーブルまたはmysqladminprocesslistコマンドからも確認できます。 PROCESS権限を持っている場合は、すべてのスレッドを表示できます。クエリID、実行時間、実行者、クライアントホストなどの情報を確認できます。MySQLのフレーバーとディストリビューション（Oracle、MariaDB、Percona）によっては、少し注意が必要な情報

SHOW PROCESSLIST;

+----+-----------------+-----------+------+---------+------+------------------------+------------------+----------+

| Id | User            | Host | db | Command | Time | State                  | Info | Progress |

+----+-----------------+-----------+------+---------+------+------------------------+------------------+----------+

|  2 | event_scheduler | localhost | NULL | Daemon  | 2693 | Waiting on empty queue | NULL   | 0.000 |

|  4 | root            | localhost | NULL | Query   | 0 | Table lock   | SHOW PROCESSLIST | 0.000 |

+----+-----------------+-----------+------+---------+------+------------------------+------------------+----------+

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

MySQLPt-query-digestの使用

特定のワークロードに関する詳細情報を確認したい場合は、pt-query-digestを使用してください。 pt-query-digestは、MySQLクエリを分析するためのPerconaのLinuxツールです。これは、ここにあるPerconaToolkitの一部です。 Debian、Ubuntu、Redhatなどの最も人気のある64ビットLinuxディストリビューションをサポートしています。

これをインストールするには、Perconaリポジトリを構成してから、perona-toolkitパッケージをインストールする必要があります。

パッケージマネージャーを使用してPerconaToolkitをインストールします：

DebianまたはUbuntu：

sudo apt-get install percona-toolkit

RHELまたはCentOS：

sudo yum install percona-toolkit

Pt-query-digestは、プロセスリスト、一般ログ、バイナリログ、低速ログ、またはtcpdumpからデータを受け入れます。それに加えて、定義された間隔でMySQLプロセスリストをポーリングすることができます-プロセスこれはリソースを大量に消費し、理想からはほど遠い可能性がありますが、それでも代替手段として使用できます。

pt-query-digestの最も一般的なソースは、遅いクエリログです。パラメータlog_slow_verbosityを使用して、そこに送信されるデータの量を制御できます。

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

microtime-マイクロ秒の精度でクエリを実行します。
query_plan-クエリの実行プランに関する情報。
innodb-InnoDB統計。

最小限-マイクロタイムだけを有効にするのと同じです。

標準-microtime、innodbを有効にするのと同じです。

full-他のすべての値と同等、またはprofilingおよびprofiling_use_getrusageオプションなしで一緒に。

プロファイリング-すべての接続ですべてのクエリのプロファイリングを有効にします。

profiling_use_getrusage-getrusage関数の使用を有効にします。

出典：Perconaのドキュメント

完全を期すために、一般的なケースであるlog_slow_verbosity=fullを使用してください。

遅いクエリログ

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

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

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

パフォーマンススキーマ

パフォーマンススキーマは、MySQLサーバーの内部と実行の詳細を下位レベルで監視するために利用できる優れたツールです。初期のバージョン（5.6）では、有効にするとパフォーマンスの問題が発生することが多かったため、評判が悪かったのですが、最近のバージョンではパフォーマンスに悪影響はありません。パフォーマンススキーマの次の表を使用して、遅いクエリを見つけることができます。

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

ネットワーク追跡クエリログまたは直接アプリケーションログにアクセスできない場合はどうなりますか。その場合、クエリのキャプチャに役立つtcpdumpとpt-queryダイジェストを組み合わせて使用できます。

$ tcpdump -s 65535 -x -nn -q -tttt -i any port 3306 > mysql.tcp.txt

キャプチャプロセスが終了したら、データの処理に進むことができます：

$ pt-query-digest --limit=100% --type tcpdump mysql.tcp.txt > ptqd_tcp.out

ClusterControlクエリモニター

ClusterControlクエリモニターは、データベースアクティビティに関する複合情報を提供するクラスターコントロールのモジュールです。 showprocesslistやslowquerylogなどの複数のソースから情報を収集し、事前に集計された方法で表示できます。

SQL監視は3つのセクションに分かれています。

上位のクエリかなりの量のリソースを使用するクエリに関する情報を表示します。

クエリの実行

これは、すべてのデータベースクラスタノードから1つのビューに結合された情報のプロセスリストです。これを使用して、データベース操作に影響を与えるクエリを強制終了できます。

クエリの外れ値実行時間が平均より長いクエリのリストを表示します。

結論これでパート2はすべてです。このブログは、データベースのパフォーマンスを向上させる方法を網羅したガイドとなることを目的としたものではありませんが、重要になる可能性のあるものと構成可能な基本的なパラメーターのいくつかをより明確に示してくれることを願っています。以下のコメントで重要なものを見逃した場合は、遠慮なくお知らせください。