About the Long_query_time settings, can be said to be a small MySQL bug?

We know that for MySQL log function, we can completely control whether to write or not. Generally speaking, binlog we usually open, and for slow queries we generally debug and observe the execution speed of SQL statements at the time of development. But today we find a problem. When using show variables like ' log% '; to see if the slow log is turned on, discover off, use set global Log_low_queries=on, and succeed. While using show variales like ' long% ' when found to be 10, so want to change it to 1, divert use set global long_query_time=1, again query discovery or 10. Just hit it, use Select Sleep (10), log the logs, and use Select Sleep (1) is not really recorded. And the set return record is:

mysql> set global long_query_time=1;

Query OK, 0 rows Affected (0.00 sec)

Really did not change, suddenly think that it is necessary to restart the server, I think it is not, I am not modifying the configuration file. Finally want to reopen a conversation to see how. Re-open a session query show variables like ' long% '; Then why is it not reflected in the window that modifies it? Puzzled.

I hope the friends who meet this situation don't keep trying in a conversation like me. Find the reason, directly open the window can be tested.

In addition, the MySQL slow query log is written to the table's setting. Set global log_output= ' TABLE ';

Another parameter related to slow queries is log_queries_not_using_indexes, which is used to set whether a query that does not use an index is logged. When this query is turned on, if your log is recorded in a table, the query records from that table will be added each time you display a slow log statement.

If the log is written in a file. You can use the Mysqldumpslow tool to browse slow query log files. The tool I have not used, after the introduction of the.

Transferred from: http://blog.csdn.net/fengbangyue/article/details/6359509

About the Long_query_time settings, can be said to be a small MySQL bug?