mysql スロー クエリ ログの query_time パラメータの計算に使用されるタイムスタンプは何ですか? そのパラメータの定義が見つかりません。私が見つけた唯一のものは
初期ロックを取得する時間は、実行時間としてカウントされません。
から: http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html
スローログの「request_time」で指定された時間に、キューでの待機時間が含まれているかどうかを知りたいので、この質問をしています (ある場合)。
いくつかのキューがある場合、新しいクエリが実行されるときに現在の待機キューの長さをログに記録する可能性はありますか (できればスロー ログに)。
キューがない場合、すべてのスレッドが現在何らかのクエリを実行している場合、mysql は着信クエリをどのように処理しますか? 更新: スレッドで実行できるようになるまで、これらのクエリを TCP バッファに保持しますか?
さらに読むためのリンクは大歓迎です。
よろしくコルビニアン
There are no queues like you describe.
When the query starts, the connection is dedicated to running it. It may be blocked by any of a large number of "mutexes" because of various things shared between connections. As the query runs, it may have to wait for I/O to read blocks from disk.
The query time in the slowlog is essentially the clock-on-the-wall time for the query. A query that normally takes 1 second may take 3 seconds if there are other connections hanging onto mutexes or doing lots of I/O.
Caching will let a query run faster. The first time you run a query (after restarting mysql), it will run slow because of all the uncached I/O.
If you are using Engine MyISAM, the "lock_time" will often be significant because of MyISAM's table locking. InnoDB rarely shows more than a fraction of a millisecond in lock_time.
In older version of MySQL, the timer was similar to TIMESTAMP with a 1-second resolution. In newer versions, it has much higher resolution.
The time at the start of a slowlog entry is the timestamp of when the query started. You may notice that the slowlog entries are not always in order according to that. This is simply because a slowlog entry is not written to the file until the query finishes.
OK, there is a queue -- but it is almost never needed. And it is at the time of establishing the connection. If there are already max_connection connections, then see back_log. I repeat, that is not a queue for executing queries.