15

したがって、スロー クエリ ログについての私の理解では、my.conf ファイルで設定した時間 (秒単位) を超えるすべてのクエリに関する情報がログに記録されるということです。

次に、3 つの異なる SELECT クエリの 3 つのケースを考えてみましょう (INNODB エンジンを使用したテーブルに対して):

クエリ I: Query_time: 32.937667 Lock_time: 0.000081 Rows_sent: 343 Rows_examined: 12714043

クエリ II: Query_time: 12.937667 Lock_time: 0.000081 Rows_sent: 43 Rows_examined: 714043

クエリ III: Query_time: 42.937667 Lock_time: 0.000081 Rows_sent: 18 Rows_examined: 483

私には、QUERY I と QUERY II の両方が、不適切なクエリ、不適切なインデックス作成 (またはインデックス作成の欠落)、または断片化されたテーブル データなどの可能性のあるケースのように見えます (見逃した可能性のあるものは他にありますか?)。 .

しかし、QUERY III の場合、私は頭を悩ませることができません。つまり、483 行を調べて 18 行を送り返すのに 42 秒かかる (ごくわずかなロック時間で) DB に実際に問題がある可能性があることを意味します。断続的に起こっているのを見ると、これはさらに混乱します。

ですから、ここで本当に聞きたいのは次のことです。

  • ロック時間情報をどのように解釈すればよいですか? 実際に実行を開始する前に、クエリが何秒も待たなければならなかったということですか? はいの場合、私の例のクエリ III では、実際に 483 行を調べるのに 42 秒かかり、そのうちの 18 行を送り返しましたか?
  • ロック時間はごくわずかですが、クエリ時間は非常に長く、数百行しか調べられずに返送される場合、どこから問題を探し始めればよいでしょうか?
  • クエリがバックグラウンド IO アクティビティに多くの時間を費やしている可能性がありますか? ロギングまたはビンロギングと言います。
  • テーブルのサイズはクエリのパフォーマンスにどの程度影響しますか? たとえば、MySQL は 2 億行以上のテーブルを処理するのに十分であると言えますか?
  • DB のバックグラウンド アクティビティを把握するために特別に DB アクティビティを監視するためのより良いツールまたは方法はありますか? 要するに、そのクエリがほとんどの時間を費やしている場所を確認することです。

このような遅いクエリに影響を与える要因は多数ある可能性があります。そのため、私を助けるためにサイドからの情報がさらに必要であると思われる場合は、お知らせください。

4

2 に答える 2

26

  • Lock time is the time spend before the query starts executing. I.e., time waiting for other threads to give up their locks on the data the current query needs to lock.

  • Query time is the time to execute the query. This may involve waiting for I/O if the rows aren't already in the buffer pool. Repeating the same query for the same data may be faster, after the data is loaded into the buffer pool.

    If your query is sorting on disk for a given query, it'll be slower even if it examines few rows.

    If your I/O system is overtaxed, you can get intermittent slowness. This also can happen to virtualized I/O (for example, cheap AWS instances). Or also if your disks are starting to fail, they may get errors intermittently.

    Monitor iostat and watch the queue length, average wait, and service time. See if there are periods of slowness, or if performance and throughput are more or less consistent.

  • Rows examined does not reflect multiple I/O's needed to fetch a given row. For example, if the row has a lot of big BLOB/TEXT/VARCHAR columns stored on overflow pages. Or if the transaction needs to visit the rollback segment to fetch old versions of some rows, if they have been modified since this transaction began.

    Rows examined also does not tell us how complex are the expressions in your query. You could be calculating Fibonacci sequences in stored functions or something crazy like that.

    Without seeing the queries and their EXPLAIN report, it's hard to make a generalization to explain the slowness, given only those numbers from the slow query log.

MySQL certainly can store 200 million rows in a table, but at that scale, you do start to get performance problems even when an index can reduce the search to 483 rows examined. That is because the depth of the B-tree index and size of an indexed column directly relate to the number of I/O operations needed to look up those 483 rows. The more I/O's, the longer it takes, and this is not reflected by rows examined. The query time includes I/O time, but does not make clear how much of the query time is due to I/O.

A few other places to look for more detailed diagnostics are:

于 2013-09-26T23:15:02.647 に答える
3

Query_time: 12.937667 Lock_time: 0.000081 Rows_sent: 43 Rows_examined: 714043

Query Time: Total time including lock time query has taken

Lock_Time: Total query query was in a locked state

Rows sent: Total rows sent by server to client

Rows examined: Total rows scanned by a MySQL server for a query
于 2013-10-04T12:38:07.090 に答える