1

mysqlslow.logの出力に問題があります。クエリmysqlslowはこれを示しており、mysqlexplainで同じことを確認しました。これは、5行のみが検査されると述べていますが、mysqlslowは約7lkh行が検査されると述べています。

さらに、私のクエリにはどこにも書かれていませんset timestamp

   # User@Host: dba[dba] @ localhost []
   # Query_time: 7.282718  Lock_time: 1.291532 Rows_sent: 0  Rows_examined: 651223
   SET timestamp=1361437845;
   SELECT *
   FROM tableA
   WHERE app='pic' and sub
   LIKE '%katrina%'
   order by id desc limit 5

ここに出力を説明します

    1 SIMPLE tableA index NULL  PRIMARY 4 NULL  5 Using where
4

1 に答える 1

4

結果セットを5行に制限しているため、5行しかありません。クエリの最後の行を参照してください。それでも、MySQLはそれらの651223行を調べて、5行だけを表示する結果セットを見つける必要があります。subこれは、LIKE句が。で始まるため、列でインデックスを使用できないため%です。列にインデックスがある場合app、いくつかの理由で使用されない場合があります。テーブルが保持している行数と比較して、明確な値が少なすぎる可能性があります。そのため、MySQLはソートに主キーインデックスを使用することを決定します（句による順序）。explainコメントであなたの結果を実際に読むことができないので、少なくとも私はそう思います。次回は、そのような情報を質問に編集してください。

これSET timestamp=1361437845は、クエリがunix_timestampとして実行された時刻です。

更新（さらに説明）：

LIKE句はLIKE '%katrina%'です。これは、「文字列のどこかにカトリーナがあり、その前後に文字がある可能性がある」という意味です。ここで、これらの基準に基づいて電話帳で誰かを調べたいと思ったと想像してみてください。電話帳がアルファベット順に並べられているという事実は、人の名前がAnkatrinaまたはZekatrinaである可能性があるため、役に立ちません。列のインデックスと同じsubです。

300万行あり、100万行に列アプリの「pic」があり、100万行に「nic」があり、100万行に「asdf」があるとします。これは、インデックスを調べてから、テーブルで実際のレコードを調べるのは実際には余分な作業であることを意味します。そのため、テーブル全体をスキャンする方が安い場合があります。しかし、私が言ったように、それは単なる推測です。データベースに関する十分な情報がありません。

インデックスがあるからといって、そのインデックスが使用される保証はありません。

EXPLAINスロークエリログではなく5行と表示される理由は、EXPLAIN実際には単なる推測であり、オプティマイザがクエリを処理する方法です。それが実際にどのように処理されるかを知りたい場合は、を使用してEXPLAIN EXTENDEDください。ここで少し注意が必要なのは、クエリで行を調べなくても、それほど多くの行を調べる必要がないということORDER BY id DESCです。次に、MySQLは実際には5行をスキャンして、結果を吐き出しますLIMIT 5。順序付けのため、おそらく最初に一時テーブルを作成し、並べ替えて、そのテーブルから5行を吐き出す必要があります。これはでは考慮されていませんEXPLAINが、で考慮されている可能性がありslow-query-logます。

于 2013-02-21T17:44:25.363 に答える