MySQLスロークエリソリューション

次の記事を転載

MySQLオープンスロークエリログ
 MySQLExplain詳細
 表示プロファイルビューSQL実行ライフサイクル

1つは、遅いクエリログを開始する

低速ログをオンにすると、小規模なプロジェクト、オンラインではないプロジェクト、または緊急事態にのみ適しています。低速ログクエリをオンにすると、データベースへの負荷が増大するためです。そのため、通常、バックグラウンドを使用してデータ操作時間をログファイルに書き込み、ログは毎週定期的にクリアされます。

パラメータの説明：

slow_query_log 慢查询开启状态，ON开启，OFF关闭
slow_query_log_file 慢查询日志存放的位置（这个目录需要MySQL的运行帐号的可写权限，一般设置为MySQL的数据存放目录）
long_query_time 查询超过多少秒才记录

遅いクエリがオンになっているかどうかを確認します

show variables like 'slow_query%';

演算結果：

ここに画像の説明を挿入

show variables like 'long_query_time';

実行結果：
ここに画像の説明を挿入
デフォルトのクエリは記録前に10秒以上です

遅いクエリを有効にする

1.グローバル変数設定（この方法でのデータベースの再起動はすべて失敗し、再構成する必要があります）

# 将 slow_query_log 全局变量设置为“ON”状态
set global slow_query_log='ON'; 
# 设置慢查询日志存放的位置
set global slow_query_log_file='/usr/local/mysql/data/slow.log'; 
# 设置查询超过1秒就记录（如果有时候用命令不起作用，那么可以关闭再打开）
set global long_query_time=1;

2. my.cnf構成ファイルを変更します（サーバーの再起動は影響しません）

構成ファイルmy.cnfを変更し、[mysqld]の下に追加します

slow_query_log = ON
slow_query_log_file = /usr/local/mysql/data/slow.log     //linux
long_query_time = 1

MySQLサービスを再起動します

service mysqld restart

次に、遅いクエリSQLを分析します

ExplainこれらのSQLステートメントの実行プランを表示し、SQLステートメントがインデックスを使用しているかどうか、および全表スキャンが実行されているかどうかを確認します。

explain select * from emp where name = 'Jefabc';

演算結果：
ここに画像の説明を挿入


id	識別子を選択
select_type	クエリの種類を示します。
テーブル	出力結果セットの表
パーティション	一致するパーティション
タイプ	テーブルの接続タイプを示します
possible_keys	クエリ時に使用できるインデックスを示します
キー	使用される実際のインデックスを示します
key_len	インデックスフィールドの長さ
ref	列とインデックスの比較
行	スキャンされた行数（推定行数）
フィルタリング	テーブル基準によってフィルタリングされた行のパーセンテージ
エクストラ	実装の説明と説明

select_typeクエリのタイプは、単一テーブルクエリ、ユニオンクエリ、サブクエリなどです。


シンプル	UNIONやサブクエリなどを使用しない単純なSELECT。
プライマリ	サブクエリの最も外側のクエリクエリに複雑なサブパーツが含まれている場合、最も外側の選択はPRIMARYとしてマークされます
連合	UNIONの2番目以降のSELECTステートメント
依存ユニオン	UNIONの2番目以降のSELECTステートメントは、外部のクエリに依存します
UNION RESULT	UNIONの結果、unionステートメントの2番目の選択により、すべての選択が開始されます
サブクエリ	サブクエリの最初のSELECT、結果は外部クエリに依存しません
依存サブクエリ	サブクエリの最初のSELECTは、外部クエリに依存します
派生	派生テーブルのSELECT句とFROM句のサブクエリ
入手不可能なサブクエリ	サブクエリの結果をキャッシュすることはできません。外部リンクの最初の行を再評価する必要があります

テーブルへのアクセスを入力します

最良から最悪の順に並べ替えます：system> const> eq_ref> ref> ref_or_null> index_merge> unique_subquery> index_subquery> range> index> all。


すべて	テーブル全体をトラバースして、一致する行を見つけます
インデックス	インデックスツリーをトラバースします
範囲	指定された範囲の行のみを取得し、インデックスを使用して行を選択します
ref	上記の表の接続一致条件、つまり、インデックス列の値を見つけるために使用される列または定数を示します
eq_ref	refと同様に、使用されるインデックスが一意のインデックス主キーまたは一意であるという違いがあります
const、system	MySQLがクエリの特定の部分を最適化し、それを定数に変換するときは、これらのタイプのアクセスを使用します。主キーがwhereリストに配置されている場合、MySQLはクエリを定数に変換できます。システムはconstタイプの特殊なケースです。クエリテーブルに行が1つしかない場合は、systemを使用します。
ヌル	MySQLは最適化プロセス中にステートメントを分解し、実行中にテーブルやインデックスにアクセスする必要さえありません。たとえば、インデックス列から最小値を選択するには、別のインデックス検索を使用できます。

possible_keys可能なインデックス

MySQLがテーブル内のレコードを検索するために使用できるインデックスを指摘します。クエリに関係するフィールドにインデックスがある場合、インデックスは一覧表示されますが、クエリでは使用されない場合があります。）

実際に使用したキーインデックス

キー列には、MySQLが実際に使用することを決定したキー（インデックス）が表示されます。これはpossible_keysに含める必要があります。

インデックスが選択されていない場合、キーはNULLです。MySQLにpossible_keys列のインデックスを使用または無視させるには、クエリでFORCE INDEX、USE INDEX、またはIGNOREINDEXを使用します。

3、SQL分析のプロファイルを表示

1.プロフィールの表示とは

これは、現在のセッションでのSQL実行のリソース消費を分析するためにmysqlによって提供されるSQLチューニング方法であり、説明よりも詳細です。デフォルトの閉じた状態で、最後の15回の実行の結果を保存します。

2.パラメータがオンになっているかどうかとオンにする方法を確認します

1.オンになっているか確認してください

show  VARIABLES like 'profiling';

操作結果：
ここに画像の説明を挿入
2。デフォルトで閉じているプロファイルを開くと、現在開いています。

set profiling = 1;

3.プロファイルを使用する

1.実行中のSQLが遅い

select * from emp group by id%10;
select * from emp group by id%20 order by 5;

2.SQLを実行します

show profiles;

演算結果：
ここに画像の説明を挿入

3. SQLを診断し、CUPの使用状況を表示します。形式：show profile cpu、block io for query [Query_ID]

show profile cpu,block io for query 12

実行結果
ここに画像の説明を挿入
ここには、CPUとブロックIOのみがリストされています。もちろん、診断タイプはこれらよりも多く、一般的に使用されているCPUとブロックIOです。

ALL 显示所有的开销信息
BLOCK IO 显示块IO相关开销
CONTEXT SWITCHES 上下文切换相关开销
CPU  显示CPU相关开销信息
IPC  显示发送和接收相关开销信息
MEMORY 显示内存相关开销信息
PAGE FAULTS 显示页面错误相关开销
SOURCE  显示和Source_function,Source_file,Source_line相关的开销信息
SWAPS   显示交换次数相关开销的信息

次の4つのステータスの発生は大きな問題を引き起こします：

converting HEAP to MyISAM ：查询结果太大，内存都不够用了往磁盘上搬
Creating tmp table ： 创建临时表，拷贝数据到临时表，用完再删除
Copy to tmp table on disk ： 把内存中临时表赋值到磁盘，很危险
locked   ：存在锁

次のように：
ここに画像の説明を挿入
tmpテーブルの作成、tmpテーブルへのコピー、tmpテーブルの削除はもちろん遅くなります

第四に、SQLの最適化

SQLステートメントの最適化