MySQLのパフォーマンス：長いクエリの識別

MySQLに裏打ちされたすべてのアプリケーションは、微調整されたデータベースサーバーの恩恵を受けることができます。 Liquid Web Heroicサポートチームは、いくつかの小さな調整によってWebサイトとアプリケーションのパフォーマンスに大きな違いが生じたときに、長年にわたって多くの状況に遭遇しました。この一連の記事では、パフォーマンスに最大の影響を与えた、より一般的な推奨事項のいくつかを概説しました。

プリフライトチェック

この記事は、ほとんどのLinuxベースのMySQLVPSサーバーに適用されます。これには、さまざまな一般的なLinuxディストリビューションを実行する従来の専用サーバーとクラウドVPSサーバーの両方が含まれますが、これらに限定されません。この記事は、次のLiquidWebシステムタイプで使用できます。

コア管理のCentOS 6x / 7x コアマネージドUbuntu 14.04 / 16.04 完全に管理されたCentOS 6/7 cPanel 完全に管理されたCentOS 7 Plesk Onyx 17 自己管理型Linuxサーバー

注直接サポートをオプトアウトした自己管理システムは、ここで説明する手法を利用できますが、Liquid Web Heroicサポートチームは、これらのサーバータイプを直接支援することはできません。

この一連の記事は、次の基本的なシステム管理の概念に精通していることを前提としています。

SSH接続と標準のLinuxコマンドラインシェル環境の基本的なナビゲーション。

Vimまたは選択したシステムエディタでファイルを開き、編集し、保存します。

MySQLインタラクティブモードと一般的なMySQLクエリ構文。

MySQL最適化とは何ですか？

MySQL最適化という用語の明確に定義された定義はありません。人、管理者、グループ、会社によって意味が異なる場合があります。 MySQL最適化に関するこの一連の記事では、MySQL最適化を次のように定義します。この一連の記事で説明されている一般的に発生するボトルネックを回避するように構成されたMySQLまたはMariaDBサーバーの構成。

ボトルネックとは何ですか？

ソーダボトルのネックと非常によく似ていますが、専門用語としてのボトルネックは、少量のトラフィックまたはデータが問題なく通過できるアプリケーションまたはサーバー構成のポイントです。ただし、同じタイプのトラフィックまたはデータの大量の処理が妨げられたりブロックされたりするため、そのままでは正常に動作できません。構成のボトルネックの次の例を参照してください。

この例では、サーバーは10個の接続を同時に処理できます。ただし、構成は5つの接続のみを受け入れます。一度に接続が5つ以下である限り、この問題は発生しません。ただし、トラフィックが最大10の接続に増加すると、サーバー構成の未使用のリソースが原因で、それらの半分が失敗し始めます。上記の例は、名前の由来となったボトルネックの形状と、ボトルネックを修正する最適化された構成を示しています。

MySQLデータベースを最適化する必要があるのはいつですか？

理想的には、データベースのパフォーマンス調整は定期的に、生産性に影響を与える前に行う必要があります。問題がアプリケーションに悪影響を与えるのを防ぐために、データベースのパフォーマンスを毎週または毎月監査することをお勧めします。パフォーマンスの問題の最も明白な症状は次のとおりです。

クエリはスタックし、MySQLプロセステーブルで完了しません。

データベースを使用するアプリケーションまたはWebサイトが遅くなります。

接続タイムアウトエラー、特にピーク時。

ビジー状態のシステムで同時に複数のクエリが実行されるのは通常のことですが、これらのクエリが定期的に完了するのに時間がかかりすぎると問題になります。特定のしきい値はシステムごとおよびアプリケーションごとに異なりますが、数秒を超える平均クエリ時間は、接続されたWebサイトおよびアプリケーション内の速度低下として現れます。これらの速度低下は、最初は小さく、大規模なトラフィックの急増が特定のボトルネックに達するまで気付かれない場合があります。

パフォーマンスの問題の特定

発生している特定のボトルネックを診断するには、MySQLプロセステーブルを調べる方法を知ることが不可欠です。特定のサーバーと設定に応じて、プロセステーブルを表示する方法はいくつかあります。簡潔にするために、このシリーズでは、Secure Shell（SSH）アクセスを介して使用される最も一般的な方法に焦点を当てます。

方法1.MySQLプロセステーブルの使用

「mysqladmin」を使用しますフラグが「プロセスリスト」のコマンドラインツール」または「proc ’の略です。（フラグ「統計」を追加します」または「統計 ’の略で、MySQLの最後の再起動以降のクエリの実行統計が表示されます。）

コマンド：

mysqladmin proc stat

出力：

 +-------+------+-----------+-----------+---------+------+-------+
 | Id    | User | Host      | db        | Command | Time | State | Info               | Progress |
 +-------+------+-----------+-----------+---------+------+-------+--------------------+----------+
 | 77255 | root | localhost | employees | Query   | 150  |       | call While_Loop2() | 0.000    |
 | 77285 | root | localhost |           | Query   | 0    | init  | show processlist   | 0.000    |
 +-------+------+-----------+-----------+---------+------+-------+--------------------+----------+
 Uptime: 861755  Threads: 2  Questions: 20961045  Slow queries: 0  Opens: 2976  Flush tables: 1  Open tables: 1011  Queries per second avg: 24.323

注：プロ：シェルインターフェイスで使用されるため、他のスクリプトやツールへの出力のパイプ処理が簡単になります。 Con ：プロセステーブルの情報列は常に切り捨てられるため、長いクエリでは完全なクエリを提供しません

方法2：MySQLプロセステーブルを使用する

MySQLインタラクティブモードプロンプト内から「showprocesslist;」クエリを実行します。（「フルコマンドの’修飾子は、の切り捨てを無効にします情報 列。これは、長いクエリを表示するときに必要です。）

コマンド：

show processlist;

出力：

MariaDB [(none)]> show full processlist;
 +-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+
 | Id    | User | Host      | db        | Command | Time | State | Info                  | Progress |
 +-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+
 | 77006 | root | localhost | employees | Query   |  151 | NULL  | call While_Loop2()    |    0.000 |
 | 77021 | root | localhost | NULL      | Query   |    0 | init  | show full processlist |    0.000 |
 +-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+

プロ：完全な修飾子を使用すると、長いクエリで完全なクエリを表示できます。 Con ：MySQL Interactiveモードでは、シェルインターフェイスで使用可能なスクリプトやツールにアクセスできません。

低速クエリログの使用

MySQLのもう1つの貴重なツールは、含まれている低速クエリロギング機能です。この機能は、実行時間の長いクエリを定期的に検索するための推奨される方法です。この機能を調整するために利用できるいくつかのディレクティブがあります。ただし、最も一般的に必要な設定は次のとおりです。

slow_query_log	遅いクエリログを有効/無効にする
slow_query_log_file	低速クエリログファイルの名前とパス
long_query_time	遅いクエリを定義する秒/マイクロ秒単位の時間

これらのディレクティブは、/ etc / my.cnfにあるMySQL構成ファイルの[mysqld]セクション内で設定され、有効になる前にMySQLサービスを再起動する必要があります。フォーマットについては、以下の例を参照してください。

警告：低速クエリログファイルには大きなディスク容量の問題があり、低速クエリログ機能が無効になるまで継続的に注意を払う必要があります。 long_query_timeディレクティブが低いほど、遅いクエリログがディスクパーティションをいっぱいにするのが速くなることに注意してください

[mysqld]
 log-error=/var/lib/mysql/mysql.err
 innodb_file_per_table=1
 default-storage-engine=innodb
 innodb_buffer_pool_size=128M
 innodb_log_file_size=128M
 max_connections=300
 key_buffer_size = 8M
 slow_query_log=1
 slow_query_log_file=/var/lib/mysql/slowquery.log
 long_query_time=5

遅いクエリログを有効にしたら、定期的にフォローアップして、パフォーマンスを向上させるために調整する必要のある手に負えないクエリを確認する必要があります。低速のクエリログファイルを分析するには、ファイルを直接解析して内容を確認します。次の例は、構成された5秒より長く実行されたサンプルクエリの統計を示しています。

注意低速クエリログ機能を有効にすると、パフォーマンスが低下します。これは、各クエリを分析するために必要な追加のルーチンと、必要なクエリをログファイルに書き込むために必要なI/Oが原因です。このため、本番システムでは、低速のクエリログを無効にすることがベストプラクティスと見なされます。遅いクエリログは、アプリケーションやウェブサイトに影響を与える可能性のある厄介なクエリを積極的に探す場合にのみ、特定の期間だけ有効にしておく必要があります。

# Time: 180717  0:23:28
 # User@Host: root[root] @ localhost []
 # Thread_id: 32  Schema: employees  QC_hit: No
 # Query_time: 627.163085  Lock_time: 0.000021  Rows_sent: 0  Rows_examined: 0
 # Rows_affected: 0
 use employees;
 SET timestamp=1531801408;
 call While_Loop2();

オプションで、mysqldumpslowコマンドラインツールを使用できます。このツールは、低速のクエリログファイルと、数値と文字列データの値を除くクエリのようなグループを解析します。

~ $ mysqldumpslow -a /var/lib/mysql/slowquery.log
 Reading mysql slow query log from /var/lib/mysql/slowquery.log
 Count: 2  Time=316.67s (633s)  Lock=0.00s (0s)  Rows_sent=0.5 (1), Rows_examined=0.0 (0), Rows_affected=0.0 (0), root[root]@localhost
 call While_Loop2()

（使用法については、こちらのMySQLドキュメントをご覧ください-mysqldumpslow —低速クエリログファイルの要約）

結論

これで、データベース最適化シリーズの最初の部分を締めくくり、ベンチマークの目的で参照するための確固たる基盤を提供します。データベースの問題は複雑になる可能性がありますが、このシリーズでは、これらの概念を分解して、データベース変換、テーブル変換、およびインデックス作成を通じてデータベースを最適化する手段を提供します。

どのように支援できますか？

私たちは、Hosting™で最も役立つ人間であることに誇りを持っています！

私たちのサポートチームは、経験豊富なLinux技術者と、複数のWebホスティングテクノロジー、特にこの記事で説明されているテクノロジーについての深い知識を持つ才能のあるシステム管理者でいっぱいです。

この情報に関してご不明な点がございましたら、24時間年中無休で、この記事に関連する問題に関するお問い合わせにいつでもお答えいたします。

フルマネージドVPSサーバー、クラウド専用、VMWareプライベートクラウド、プライベート親サーバー、マネージドクラウドサーバー、または専用サーバーの所有者であり、概説されている手順のいずれかを実行することに不安がある場合は、このプロセスを支援するためのチャットまたはサポートチケットである@800.580.4985に電話で連絡できます。

シリーズナビゲーション次の記事>>