optmizing ORDER BY in MySQL

A few days back we were trying to optimize a sql query that was using an ORDER BY clause. When we ran an EXPLAIN on the query, we saw that the query was Using filesort and Using temporary. Since this query was run quite frequently, there was a benefit in optimizing this.

I had been under the impression that if your query uses filesort and then has to use temp tables for sorting, you cannot do much to save the query. However, that is not the case. If you have an index on the column being used to do the order by , mysql will use that index for sorting. Of course, there are caveats to this, the most important one being

The key used to fetch the rows is not the same as the one used in the ORDER BY: SELECT * FROM t1 WHERE key2=constant ORDER BY key1;

Hence, if you have a query which requires to be sorted, and it is being run quite frequently, it makes sense to add an index on the column on which you are doing the sort.

happiness is ..

knowing you can still understand output from diff, even though it has been months you touched any code.

debugging malloc

Have you read the man malloc page recently? Did you notice this section there

Recent versions of Linux libc (later than 5.4.23) and GNU libc (2.x) include a malloc implementation which is tunable via environment variables. When MALLOC_CHECK_ is set, a special (less efficient) implementation is used which is designed to be tolerant against simple errors, such as double calls of free() with the same argument, or overruns of a single byte (off-by-one bugs). Not all such errors can be protected against, however, and memory leaks can result. If MALLOC_CHECK_ is set to 0, any detected heap corruption is silently ignored; if set to 1, a diagnostic is printed on stderr; if set to 2, abort() is called immediately. This can be useful because otherwise a crash may happen much later, and the true cause for the problem is then very hard to track down.

So, you can do export MALLOC_CHECK_=1 and malloc will print debugging messages to the stderr.