There is a popular myth about the SQL GROUP BY clause. The myth holds that ’standard SQL’ requires columns referenced in the SELECT list of a query to also appear in the GROUP BY clause, unless these columns appear exclusively in an aggregated expression. MySQL is often accused of violating this standard.

In this article I will attempt to debunk this myth, and to provide a more balanced view regarding MySQL’s treatment of GROUP BY at the same time.

Shortly before MySQL Users Conference I announced that I would be cover new ground in table logs management.
I am keeping that promise, and in addition I am also showing some related hacks.

The announced facts from last year usability report were that you can't change log tables at will, as you can do with log files, and you can't change the log table engine to FEDERATED. Both claims, as it turned out, were incorrect. You can do such things, albeit not in a straightforward manner. As a bonus side effect, you can also:

• add triggers to log tables;
• filter log tables depending on user defined criteria, such as query type, user database, or time;
• centralize logs from several servers.

Thought I’d pass along this note I received, that may be of interest to the MySQL addicts out there:

>> Sasha Pachev, whose book Understanding MySQL Internals was released
>> last month by O’Reilly, is leading an online seminar at MySQL AB on
>> “Improving query performance through a better understanding of the
>> optimizer”:
>>
>> https://www.mysql.com/news-and-events/web-seminars/sasha.php
>>
>> You can present Sasha with your own SQL queries during this webinar
>> and learn how to interpret output of the EXPLAIN command to improve
>> your performance. This webinar is also a useful accompaniment to
>> Understanding MySQL Internals, which contains extensive information
>> on EXPLAIN and the behavior of the optimizer exposed by it