ここにファイルをドロップします

SQL アップロード ( 0 ) x -

ページ関連の設定 バーをクリックしてページ上部にスクロール
クエリを実行するには、Ctrl キーを押しながら Enter キーを押します Enter キーを押してクエリを実行する
昇順
降順
順序:
SQL のデバッグ
カウント
実行順
所要時間
並び順:
グループクエリ
クエリのクループを解除
折りたたむ 展開 トレースを表示 トレースを非表示 件数: 所要時間:
オプション
デフォルト値に戻す
折りたたむ 展開 再クエリ 編集 EXPLAIN プロファイリング 問い合わせ失敗 データベース: 問い合わせた時間:

アドバイザ・システム

パフォーマンス的に検討が推奨される事象

問題：
稼働時間が 1 日未満です。パフォーマンスチューニングが正確でない可能性があります。
推奨設定：
統計データをより正確にするために、サーバを 1 日以上稼動させてから解析することをお勧めします
判断理由：
0 日 0 時間 11 分 12 秒 しか稼動していません
判断値の算出方法：
Uptime
判断基準：
value < 86400
問題：
long_query_time は 10 秒以上に設定されています。従って、10 秒を超えるものがスロークエリとしてログに記録されます。
推奨設定：
環境によっては、long_query_time を低い値に設定したほうがいいでしょう。通常、1～5 秒の値が推奨されます。
判断理由：
long_query_time は現在 10 秒に設定されています。
判断値の算出方法：
long_query_time
判断基準：
value >= 10
問題：
スロークエリログが無効になっています。
推奨設定：
slow_query_log を「ON」に設定することで、スロークエリログが有効になります。これは、パフォーマンスの悪いクエリの切り分けに役立つでしょう。
判断理由：
slow_query_log が「OFF」に設定されています
判断値の算出方法：
slow_query_log
判断基準：
value == 'OFF'
問題：
準最適キャッシュ方式です。
推奨設定：
MySQL のクエリキャッシュをかなりトラフィックの高いデータベースに対して使用しています。 MySQL のクエリキャッシュの代わりに memcached の使用を検討する価値があると思われます。これは、複数のレプリカを使用している場合は、特に推奨します。
判断理由：
クエリキャッシュが有効になっており、サーバが毎秒 164 個のクエリを受信しています。毎秒 100 個を超えるクエリがある場合、このルールが適用されます。
判断値の算出方法：
Questions / Uptime
判断基準：
value > 100
問題：
ソートされている行が多く存在します。
推奨設定：
大量の行のソートを行うことに問題はありませんが、大量のソートを必要とするクエリでは、 ORDER BY 句でインデックス付きのカラムを使用するようにした方が、より高速なソートが可能になるでしょう。
判断理由：
ソートされた行数の平均: 541.65 / 秒
判断値の算出方法：
Sort_rows / Uptime
判断基準：
value * 60 >= 1
問題：
インデックスを使用しない結合が多くあります。
推奨設定：
これは結合において、テーブルが全スキャンされていることを示しています。結合条件に合ったカラムにインデックスを追加することで、テーブル結合のスピードは大幅に上がるでしょう。
判断理由：
テーブル結合の平均は 189.43 / 秒 です。この値は、1 時間当たり 1 未満であるべきです
判断値の算出方法：
(Select_range_check + Select_scan + Select_full_join) / Uptime
判断基準：
value * 60 * 60 > 1
問題：
最初のインデックスエントリを読み込む割合が高いです。
推奨設定：
これは、通常、インデックスの全スキャンが頻繁に行われていることを示しています。インデックスの全スキャンはテーブルのスキャンよりは速いですが、大きなテーブルでは CPU リソースを多く必要とします。このテーブルに対して UPDATE や DELETE が多く行われたまたは行われているのであれば、「OPTIMIZE TABLE」を実行することでインデックスの全スキャンの減少やスキャンスピードの上昇が見込めるかもしれません。また、インデックスの全スキャンは、クエリを書き直すことでも減らすことが可能です。
判断理由：
インデックススキャンの平均が 89.54 / 秒 です。この値は、1 時間当たり 1 未満であるべきです
判断値の算出方法：
Handler_read_first / Uptime
判断基準：
value * 60 * 60 > 1
問題：
決まった位置のデータを読み込む割合が高いです。
推奨設定：
多くのクエリがインデックスを使用しない結合クエリを含んでいるために、結果のソート、テーブルの全スキャン、のいずれかもしくは両方を必要としていることを示しています。該当箇所にインデックスを追加してください。
判断理由：
決まった位置を読み込む割合の平均は 94.49 / 秒 です。この値は、1 時間当たり 1 未満であるべきです
判断値の算出方法：
Handler_read_rnd / Uptime
判断基準：
value * 60 * 60 > 1
問題：
テーブルの次行を読み込む割合が高いです。
推奨設定：
多くのクエリがテーブルの全スキャンを行っていることを示しています。該当箇所にインデックスを追加してください。
判断理由：
テーブルの次行を読み込む割合が 12358.67 / 秒 です。この値は、1 時間当たり 1 未満であるべきです
判断値の算出方法：
Handler_read_rnd_next / Uptime
判断基準：
value * 60 * 60 > 1
問題：
多くの一時テーブルが、メモリではなくディスク上に展開されています。
推奨設定：
max_heap_table_size と tmp_table_size を増加させることで改善されるかもしれません。しかしながら、これらの変数値に関わりなく、常にディスクに展開される一時テーブルは存在します。この状況をも改善したいのであれば、BLOB や TEXT のカラムもしくは 512 バイトを超えるカラムを使わないように、クエリを書き直す必要があるでしょう。このことは、MySQL ドキュメントに詳しく記載しています
判断理由：
ディスク書き込みを伴う一時テーブル割合は 1.79 / 分 です。この値は、1 時間当たり 1 未満であるべきです
判断値の算出方法：
Created_tmp_disk_tables / Uptime
判断基準：
value * 60 * 60 > 1
問題：
MyISAM キーバッファ (インデックス キャッシュ) の使用率 % が低いです。
推奨設定：
key_buffer_size の必要とするサイズが減少しているようです。ご使用のテーブルでインデックスが削除されていないかよく確認してください。また、クエリあるいはインデックスの使用が想定されるものがないか確認してみてください。
判断理由：
使われている MyISAM キーバッファの最大比率は 0% です。この値は 95% より大きくすべきです
判断値の算出方法：
Key_blocks_used * key_cache_block_size / key_buffer_size * 100
判断基準：
value < 95
問題：
テーブルを開く割合が高いです。
推奨設定：
テーブルを開くと、高負荷のディスク入出力を必要とします。 table_open_cache を大きくすると、これを避けられるかもしれません。
判断理由：
テーブルを開く割合は 1.43 / 秒 です。この値は、1 時間当たり 10 未満であるべきです
判断値の算出方法：
Opened_tables / Uptime
判断基準：
value*60*60 > 10
問題：
開いているファイルの割合が高いです。
推奨設定：
open_files_limit 増やすことを検討してください。open_files_limit を変更して再起動した場合は、エラーログを確認するようにしてください。
判断理由：
開いているファイルの割合は 53.57 / 時 です。この値は、1 時間当たり 5 未満であるべきです
判断値の算出方法：
Open_files / Uptime
判断基準：
value * 60 * 60 > 5
問題：
中断された接続が多いです。
推奨設定：
接続は中断されたというのは、一般的に、認証できなかった場合のことです。この記事 (英語) は、原因を突き止めるのに参考になるかもしれません。
判断理由：
中断された接続の割合は 16.07 / 時 です。この値は、1 時間当たり 1 未満であるべきです
判断値の算出方法：
Aborted_connects / Uptime
判断基準：
value * 60 * 60 > 1