We inadvertently provisioned a few database machines with MyISAM instead of InnoDB, and it has been a nightmare. I strongly advice against using MyISAM -- ever.

With MyISAM, we periodically get these incorrect "duplicate key" errors that don't go away until you run the lenghty "repair table" command that somehow fixes everything.

Quoted: Use MyISAM when: The data isn't too critical ( "unreliable and slow, related to table size, table repair process" )
...
Use InnoDB for tables when: The table will be big (100Mb+ - "For reliability and performance, we use InnoDB for almost everything at Wikipedia - we just can't afford the downtime implied by MyISAM use and check table for 400GB of data when we get a crash." )

Looks like a great set of tools for MySql.

Quoted: Essential command-line utilities for MySQL (formerly MySQL Toolkit)

Some of the referenced blog posts are quite interesting, too.

Quoted: There are interesting posts these day about future of MySQL Replication by Brian Frank and Arjen. I think it very interesting to take a look at a bit bigger picture using framework from Innovators Dilemma and Innovators Solution.
...
All these requirements made traditional databases irrelevant for many web properties - too complex and too expensive to start with.

Drupal 6.0 was released today.

Quoted: These changes are evident in Drupal 6's major usability improvements, security and maintainability advancements, friendlier installer, and expanded development framework. Further, from bug fix to feature request, these issues follow-through on the Drupal project's continued commitment to deliver flexibility and power to themers and d

You have to assume that there will be replication lag. Having said that, chopping up long queries into smaller ones (if using replication) is a good rule of thumb.

Quoted: And the final advice - do not assume very short lag time when planning your application. Having application which can adapt to lag time rather than break is very good idea. Especially it will be handy when you will be reaching replication capacity and will need to buy time to fix things, during which replication lag can be higher than normally.

Quoted: Today I would like to share practical example when you may use long primary key with value distribution far from sequential.
...
This table is getting much more reads than writes so transactional overhead of for writes is small price to pay for number of benefits - caching data and index in memory -so cached lookups are very fast, clustering by primary key

We're using 1.0.7 -- making these changes has helped our performance in our test environment.

Quoted: The 2 I'm mainly interested in are CacheServerConfig and ResetPooledConnections, as in 1.0.7 these made such a difference that (for our application) the connector went from unusable to very efficient. Now, with the 1.0.9 source, it looks like the 3 accepted options for connection reset ("reset pooled connections", "resetpooledconnections", "reset connections") have been replaced with 1: "connection reset". As for CacheServerConfig, it simply doesn't exist any more. The code where it came into play has been changed (if my quick interpretation is correct) to always behave as if it were set to TRUE in 1.0.7. What's the logic of *removing* configurability?

Quoted: Looking at how people are using COUNT(*) and COUNT(col) it looks like most of them think they are synonyms and just using what they happen to like, while there is substantial difference in performance and even query result.