(Rob Gravelle) Using MySQL analysis tools, you can identify and optimize slow queries in order to eliminate the bottlenecks that they cause.

(Giuseppe Maxia) If you like fresh features, you should not miss this one. MySQL 5.6.2 includes, among other improvements, the implementation of Time delayed replication, a feature that lets you tell the slave not to apply changes from the master immediately, but to wait N seconds.

(Baron Schwartz) InnoDB’s checkpoint algorithm is not well documented. It is too complex to explain in even a long blog post, because to understand checkpoints, you need to understand a lot of other things that InnoDB does.

(Martin Farach-Colton) In part one, I presented a very brief and particular view of partitioning. I covered what partitioning is, with hardly a mention of why one would use partitioning. In this post, I’ll talk about a few use cases often cited as justification for using partitions.

(Shlomi Noach) A simple question I’ve been asked: Is it possible to merge two UPDATE queries, each on different WHERE conditions, into a single query?

(Domas Mituzas) I remember various discussions in different mediums where people were building cases against use of FORCE INDEX in SQL queries. I’ll hereby suggest it using way more often, but at first I’ll start with small explanation.

(Frazer) When MySQL AB bought Sun Microsystems in 2008 (or did Sun buy MySQL?), most of the MySQL team merged with the existing Database Technology Group (DBTG) within Sun.

The easiest way to generate random rows in MySQL is to use the ORDER BY RAND() clause.

(Ivan Zoratti) They come back, every now and then. Subqueries are far from being perfect at MySQL and they can give you some serious headaches.

(Martin Farach-Colton) Partitioning is a commonly touted method for achieving performance in MySQL and other databases. (See here, here, here and many other examples.) I started wondering where the performance from partitions comes from, and I’ve summarized some of my thoughts here.