Bug #1580 OPTIMIZE & REPAIR queries being logged into slow_query_log
Submitted: 16 Oct 2003 15:23 Modified: 14 Nov 2003 5:16
Reporter: Ilia Alshanetksy Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server Severity:S4 (Feature request)
Version:3.23.58 OS:Linux (Linux 2.4.21)
Assigned to: Sergei Golubchik CPU Architecture:Any

[16 Oct 2003 15:23] Ilia Alshanetksy 
Description:
Optimize & repair queries that often take a substancial amount of time are being logged into the slow query log. This is fairly pointless since neither query can be optimized.

How to repeat:
OPTIMIZE large_table;
[16 Oct 2003 18:27] Paul DuBois 
Why is this a bug? The slow query log is useful
for identifying queries that may be subject to
optimization, but that is not its only use. It also
indicates queries that may be consuming server
resources, and OPTIMIZE/REPAIR may fall into
that category.
[17 Oct 2003 0:17] Alexander Keremidarski 
To extend what Paul said.

OPTIMIZE & REPAIR not only take resources. They also keep tables locked so other sessions can't use them which means these queries are strong candidates for investigation.

This is exactly what slow log is for - to log troublesome queries.
[17 Oct 2003 2:24] Sergei Golubchik 
Still, I agree that this behaviour is inconsistent, as MySQL does not log *some* commands, that are expected to be slow, namely COM_TABLE_DUMP and COM_BINLOG_DUMP.

This is going to be fixed (is some way or another - I don't know yet which).
[14 Nov 2003 5:16] Sergei Golubchik 
Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html

fixed in 4.1.1 - as it's a change in behaviour that cannot be done in the stable branch