Is a way to prevent a single query from appearing in mysql slow query log?
One may actually disable logging before executing the query (by setting a global variable) and enable it back after the query, but this would prevent logging in other threads as well, which is not desirable.
Do you have any ideas?
In MySQL 5.1 and later, you can make runtime changes to the time threshold for which queries are logged in the slow query log. Set it to something ridiculously high and the query is not likely to be logged.
SET SESSION long_query_time = 20000;
SELECT ...whatever...
SET SESSION long_query_time = 2;
Assuming 2 is the normal threshold you use.
I don't know if you can prevet a single query from appearing in the slow query log, but you could use a grepped output from the query log. Having said that, if I remember correctly, every slow query is dumped as multiple lines so it would not be easy to grep it out, but not impossible.
mysqldumpslow has a "-g pattern" option to "Consider only queries that match the (grep-style) pattern." which may help in your situation.
I hope this helps.
Cheers
Tymek
Related
I enabled below variable in my.cnf:
log_slow_queries = "/var/log/mysql/mysql-slow.log"
long_query_time = 2
log-queries-not-using-indexes
and restarted the MySQL service. Then mysql-slow.log keeps recording 2 queries (both are small table with full scan, no index involved) repeatedly every 5 seconds. Both of the queries actually took less than 0.01 second. and the log file becomes bigger and bigger.
My server version: 5.5.31-0ubuntu0.12.04.1-log (Ubuntu).
I wonder how frequently the log file will do the writing job, even a redundant job? Can we control some other system variables to slow down this work? There are also some similar question, such as:
rotating mysql slow query log
Mysql slow query log is logging faster queries
Logging slow queries in MySQL
......
Can some experts explain it?
Thanks very much!
As per documentation on the slow query log, this is by design
The server uses the controlling parameters in the following order to
determine whether to write a query to the slow query log:
The query must either not be an administrative statement, or
--log-slow-admin-statements must have been specified.
The query must have taken at least long_query_time seconds, or
log_queries_not_using_indexes must be enabled and the query used no
indexes for row lookups.
The query must have examined at least min_examined_row_limit rows.
Also, further explanation on what this variable setting does,
If you are using this option with the slow query log enabled, queries
that are expected to retrieve all rows are logged. See Section 5.2.5,
“The Slow Query Log”. This option does not necessarily mean that no
index is used. For example, a query that uses a full index scan uses
an index but would be logged because the index would not limit the
number of rows.
The queries will be logged every time they fire, until they are modified to not match the behavior triggering their log. You can rotate the logs if you're concerned about diskspace, as suggested in one of the questions you linked. See this literature on logrotate and example configuration.
Does mysql server keeps records of queries executed on it, if it does so , is it possible to retrieve those queries.
Thanks.
You can use the General Query Log, which logs all queries in plain text.
We have this enabled on our development environment only. It shouldn't be a problem to turn this on temporarily on a production server during off-peak times.
If you're looking for slow queries, you may as well use the Slow Query Log.
If you want to keep record of all queries that are executed, you can enable either the General Query Log or the Slow Query Log and set the threshold to 0 seconds (any query that takes more than 0 seconds will be logged).
Another option is the Binary log. However, binary log does not keep record of queries like SELECT or SHOW that do not modify data.
Note that these logs get pretty big pretty fast in a server with traffic. And that both might contain passwords so they have to be protected from unauthorized eyes.
You can use MySQL Proxy which stands between client app and RDBMS itself.
http://forge.mysql.com/wiki/MySQL_Proxy
You can see online queries and also it allows you to rewrite queries based on rules.
There's another option - use a profiler.
For instance: http://www.jetprofiler.com/
I have a slow MySQL query in my application that I need to re-write. The problem is, it's only slow on my production server and only when it's not cached. The first time I run it, it will take 12 seconds, then any time after that it'll be 500 milliseconds.
Is there an easy way to test this query without it hitting the query cache so I can see the results of my refactoring?
MySQL supports to prevent caching single queries. Try
SELECT SQL_NO_CACHE field_a, field_b FROM table;
alternatively you can diasble the query cache for the current session:
SET SESSION query_cache_type = OFF;
See http://dev.mysql.com/doc/refman/5.1/en/query-cache.html
To add to johannes's good answer, what I do is
RESET QUERY CACHE;
This has the slight added advantage of not requiring any changes to either the statements I'm executing or the connection.
A trivial thing to do is to alter the statement you're executing somehow, such as put a random number in a comment, because a queries are located in the cache only if they are byte-identical to some previous query.
How would i monitor a MySQL to detect SELECTs which are running slowly? Having identified a poorly performing SELECT, how would i analyse it with a view to improving it?
You would enable slow query logging, e.g. add this to your my.cnf under the [mysqld] section
set-variable=slow_query_log=on
set-variable=long_query_time=20
This will log all queries taking 20 seconds or more to a "hostname"-slow.log, e.g. /var/lib/mysql/localhost-slow.log
You'd then inspect those queries, and at least run EXPLAIN on them, and figure out what makes it slow, e.g. add indexes, rewrite the SQL etc. - though optimizing queries is a whole other book.
MySQL keeps a 'slow query log' which will provide you with information about slow running queries.
I think it's enabled by default, and its location is set in your MySQL .ini file.
See here for more information on the slow query log.
You can use EXPLAIN to get information about how MySQL is executing your queries - just put EXPLAIN before your query. There is a good article here on how to interpret the results.
I have some strange bug into a application(or is it the MySQL build?) that causes queries to remain in "locked" state forever, filling up the max number of threads.
I read about setting the wait_timeout variable to kill the "bogus" threads after a period of time. This works ok, but I would like to log the killed queries for further inspection/making sure backup scripts are not killed.
Is there any possibility to do that?
Thanks.
You might be able to use the slow log, but I'm not sure if the problem is that they never complete. Worth a shot.
Also, you may be able to see what's going on by running SHOW FULL PROCESSLIST while you've got dead threads. It should show you what the problem is and what the query was.
If you can simulate this in a development environment, you could also turn on general query logging (which records every statement) and then just tail the log after it crashes.
In the past, I have tagged queries with a unique comment (per query type):
/* Query_12345 */ SELECT ... FROM ... WHERE ... LIMIT ...
A background process would poll SHOW FULL PROCESSLIST and look for any queries that were more than X seconds long, and tagged with Query_NNNNN.
Finally, it would kill them if they went on too long. This allowed the server to breath while we figured out how to optimize the 80,000,000 record table that was slowing things down.