If the unit of time in MySQL's slow-query log is second (according to the SO answer), what does the following line from my MySQL's slow-query log mean?
# Query_time: 18446744073709.550781 Lock_time: 0.000062 Rows_sent: 1 Rows_examined: 2
This request should take more than 500 years? ..
Related
I executed the LIKE clause SQL twice as below.
My table has 50000 rows and the first SQL returns 50000 rows.
On the other hand, the second SQL returns 0 rows.
I thought that in both cases MySQL had to examine all 50000 rows to execute.
but Why is Query_time of the second SQL much faster than the first one?
Am I missing something?
Does Rows_sent influence Query_time?
If so, how does it affect?
# Query_time: 4.575865 Lock_time: 0.000120 Rows_sent: 50000 Rows_examined: 50000
SELECT * FROM `XXXX` WHERE `XXXX` LIKE "%Tom%";
# Query_time: 0.163456 Lock_time: 0.000128 Rows_sent: 0 Rows_examined: 50000
SELECT * FROM `XXXX` WHERE `XXXX` LIKE "%TTTTTTTTOOOOOOOOOOOMMMMMMMMM%";
I'm using Amazon Aurora MySQL3 (with MySQL 8.0 compatibility).
Thank you in advance.
It takes some effort [that is, time] to package up the rows and send them to you.
This question already has an answer here:
Rails SELECT 40001 SQL_NO_CACHE fired from unknown place
(1 answer)
Closed 3 years ago.
While I'm exploring logs from CloudWatch, I found some queries I can't explain
# Time: 190726 1:05:16
# User#Host: company[company] # [210.10.5.183] Id: 938
# Query_time: 238.040510 Lock_time: 0.000033 Rows_sent: 8988370 Rows_examined: 8988370
use application;
SET timestamp=1564103116;
SELECT /*!40001 SQL_NO_CACHE */ * FROM `dictionary_translations`;
# Time: 190726 1:09:53
# User#Host: company[company] # [210.10.5.183] Id: 938
# Query_time: 277.528088 Lock_time: 0.000035 Rows_sent: 3223714 Rows_examined: 3223714
SET timestamp=1564103393;
SELECT /*!40001 SQL_NO_CACHE */ * FROM `email_events`;
...
As you can see these queries took a lot time, it must be optimized.
The application runs on rails, maybe Active Record is doing some synchronization?
What is the 'nature' of these queries? How it can be optimized?
The nature of this queries may be result of running mysqldump while backing up database
I am having a very strange situation in which i have mysql version 5.5.46 working with engine innoDB.
I have enables slow_log and long_query_time is set on 3 seconds,
and although i have in the slow log queries that finished with in less than 0.5 second and more queries such as selects/updates and inserts that finish with in 0.000037 seconds.
# Query_time: 0.002699 Lock_time: 0.000037 Rows_sent: 0 Rows_examined: 1
I checked weather i have enabled the parameter log_queries_not_using_indexes but it is OFF.
I tried to disable slow-log set in to off then on.
I tried on setting the long_query_time to 10 seconds but it does not help the issue.
Restart is not an option currently on a production system.
I searched everywhere for solution, the only thing i can think on is to set the global variable: min_examined_row_limit to more than 1 since almost all of the queries that finish with in less than 1 second examine only 1 row, but i would not want that because it may hide problems later.
Some of the logs for example:
INSERT INTO xxx (X values);
# Time: 170521 9:47:46
# Query_time: 0.006520 Lock_time: 0.000041 Rows_sent: 0 Rows_examined: 1
SET timestamp=1495374466;
UPDATE 'schema_name'.'replication_heartbeat' SET ts='2017-05-21T09:47:46.000720', file='test-db44-bin.089771', position='10638144', relay_master_log_file=NULL, exec_master_log_pos=NULL WHERE server_id='44';
# Time: 170521 9:47:47
# Query_time: 0.014305 Lock_time: 0.000043 Rows_sent: 0 Rows_examined: 1
SET timestamp=1495374467;
UPDATE 'schema_name'.'replication_heartbeat' SET ts='2017-05-21T09:47:47.000700', file='test-db44-bin.089771', position='10760016', relay_master_log_file=NULL, exec_master_log_pos=NULL WHERE server_id='44';
Does anyone have any idea of how to remove all that junk from the slow log?
Thanks everyone,
Leon.
I'm having some issues logging the slow queries in my MySQL 5.1 instance. It seems to be logging every query, not just the slow ones.
Here's a sample of the logging...
# User#Host: root[root] # localhost [127.0.0.1]
# Query_time: 0.000000 Lock_time: 0.000000 Rows_sent: 1 Rows_examined: 11
SET timestamp=1398191470;
SELECT count(distinct(user_id)) as user_id from user_sessions where role='bidder';
# User#Host: root[root] # localhost [127.0.0.1]
# Query_time: 0.000000 Lock_time: 0.000000 Rows_sent: 9 Rows_examined: 11
SET timestamp=1398191470;
SELECT user_name FROM user_sessions WHERE last_access_ts > '2014-04-22 14:30:59';
Here's the entries in my mysql.ini file....
long_query_time = 3
slow_query_log
log-queries-not-using-indexes
You have "log-queries-not-using-indexes" turned on. That causes the server to consider all queries that are not using indexes to be "slow".
To resolve your issue, either remove "log-queries-not-using-indexes" or add indexes on "role" and "last_access_ts" fields to user_sessions table.
The MySQL slow query log often shows a bunch of following entries in sequence.
SET timestamp=1268999330;
commit;
# User#Host: username[username] # localhost []
# Query_time: 4.172700 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0
SET timestamp=1268999330;
commit;
# User#Host: username[username] # localhost []
# Query_time: 3.628924 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0
SET timestamp=1268999330;
commit;
# User#Host: username[username] # localhost []
# Query_time: 3.116018 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0
...
Usually 6-7 "commit" queries in sequence. Anyone what they are and what's the preceding query of each of them?
Thanks in advance.
the set timestamp command affects the value returned by now and the value that auto timestamp columns receive when their rows are modified.
this is necessary for replication and when playing back the log. query semantics that depend on the current time will always match exactly. (note sysdate disregards set timestamp unlike now)
the log will make sure the timestamp is recorded with set timestamp whenever there's a new connection, a mysql ping, or any statement executed.