MySQL Handler_read_rnd_next ==インデックスなしのテーブルスキャン？
私はPercona 5.5サーバーのチューニングを行っており、perconaのツールを使用してデータベースのパフォーマンスをプロットしています。 MySQLハンドラープロットでは、「Handler_read_rnd_next」呼び出しの多くに気付いています。
Mysql dev docuでいくつかの掘り下げを行った後、このハンドラーはおそらく次のことを示します： "これは、テーブルが適切にインデックス付けされていないか、クエリが作成したインデックスを利用していないことを示唆しています"
次に、オプション付きのtcpdumpおよびmk-query-digest（素晴らしいツールbtw）の助けを借りて、インデックス付けされていない呼び出しのクエリの分析を開始しました。
- --filter '（$ event-> {No_index_used} eq "はい" || $ event-> {No_good_index_used} eq "はい"）'
しかし、空白を描画しています。インデックスを使用していないものとしてリストされているすべてのクエリは、「派生」選択タイプがどこかにあり、すべて数ミリ秒以内に完了します。
したがって、私の質問：派生した選択タイプがインデックスのない唯一のものである場合、私のHandler_read_rnd_nextインスタンスはどこから来ますか？私は問題が何であるかを見つけるために私が得ることができるどんな助けにも感謝します。
ありがとう！
slow-query-log および log-queriesを有効にする必要があります-not-using-indexes toを使用して、インデックスでスキップされているクエリを明示します。
これは単なる個人設定ですが、通常は mk-query-digest の--processlistオプションを使用します。私はそのための自動化スクリプトをずっと前に書きました： MySQLの一般的なクエリログのパフォーマンス効果に基づいています遅いログ 。
クエリが認識されると、すべての選択に対してEXPLAINが実行されます。 EXPLAINプランがインデックスの選択に失敗したクエリは、テーブルスキャンを行うことで有罪となります。