Today I noticed one of server used for web request profiling stats logging is taking about 2GB per day for logs, which are written in MyISAM table without indexes. So I thought it is great to try how much archive storage engine could help me in this case.
[read more...]
As you probably know PHP “mysql” extension supported persistent connections but they were disabled in new “mysqli” extension, which is probably one of the reasons some people delay migration to this extension.
The reason behind using persistent connections is of course reducing number of connects which are rather expensive, even though they are much faster with MySQL than with most other databases.
[read more...]
One think I can see with people using EXPLAIN is trusting it too much, ie assuming if number of rows is reported by EXPLAIN is large query must be inefficient. It may not be the case.
The question is not only about stats which may be wrong and which is why you may want to profile your queries if you have any hesitations in EXPLAIN accuracy.
The other problem however is EXPLAIN does not take LIMIT into account while estimating number of rows. Basically it gives you the estimates of producing whole result set while it may stop much faster in case LIMIT is used.
Take a look at this simple example:
This EXPLAIN estimates there would be almost 50.000 of rows scanned while really there would be only 1. Same applies to full table scans with limit.
The other little annoyance is - MySQL will report these queries to slow query log if --log-queries-not-using-indexes is enabled which may flood it quite badly. Too bad --min-examined-row-limit is not yet implemented 
EXPLAIN would also return misleading number of rows for queries of the type:
SELECT ... FROM TBL WHERE KEY_PART1=CONST ORDER BY KEY_PART2 LIMIT N
In this case it would not be considered full table scan and reported to slow query log however.
del.icio.us
digg