| Bug #71767 | Is it reasonable that lock_time is not included when decide SERVER_QUERY_WAS_SLO | ||
|---|---|---|---|
| Submitted: | 19 Feb 2014 4:45 | Modified: | 24 Jul 2014 19:51 |
| Reporter: | xiaobin lin (OCA) | Email Updates: | |
| Status: | Not a Bug | Impact on me: | |
| Category: | MySQL Server | Severity: | S3 (Non-critical) |
| Version: | all | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | discussion, Lock_time, long_query | ||
[24 Jul 2014 19:51]
Sveta Smirnova
Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://dev.mysql.com/doc/ and the instructions on how to report a bug at http://bugs.mysql.com/how-to-report.php According to http://dev.mysql.com/doc/refman/5.6/en/slow-query-log.html: "The time to acquire the initial locks is not counted as execution time. mysqld writes a statement to the slow query log after it has been executed and after all locks have been released, so log order might differ from execution order. " So this is not a bug. If you need to count initial locking time use Audit plugins.
Description: As in the code " void update_server_status() { ulonglong end_utime_of_query= current_utime(); if (end_utime_of_query > utime_after_lock + variables.long_query_time) server_status|= SERVER_QUERY_WAS_SLOW; } " This means that when deciding whether the query is a slow_query, the lock time is excluded. Is it reasonable? Will it be better to use start_utime to instead utime_after_lock here? How to repeat: as above