Installing Django and MySQL on Mac OS X 10.7 from a fresh install.
( In point form, because I'm in a hurry. )

There comes a time in every DBA's life when they wish they could have a "scratchpad" database in which to futz around with junk that might break other databases.

( Gory technical details behind the cut )

Say you have a MySQL database on one machine, which you want to move to a new machine. The database on disk takes up 60G of space. Oh, and you want to test some potentially destructive software using this database.

( What do you do? )

Dear MySQL,

It would be really nice if Ctrl+C could just abort the current instruction rather than quit the shell. It would be really nice if you'd tell me that "BEGIN WORK" doesn't work, rather than telling me that "COMMIT" and "ABORT" don't work.

Dear Self,

Learn to type the "WHERE" clause first, before specifying what columns to update.

Based on the articles "Speeding up Django tests using a RAM-bound MySQL server" and "Create a RAM Disk in Mac OS X" I managed to cobble together a little script to start up a RAM-disk based MySQL server to make my Django tests go faster on Mac OS X.

( Using a RAM disk sped up my test suite from about an hour to about 7 minutes. )

I was watching Activity Monitor to see how much of the systems resources MySQL was using while running my test suite, and on the list of top processor usage was "mds" which is of course the Spotlight indexing engine.
( Not being particularly interested in using Spotlight to search for records inside the MySQL database, I turned it off )

Every time I say "Snow Leopard" I keep thinking of that guy on stage with the German accent... but that's not what I'm here to write about.
( Post will be updated as I prepare for and execute a Snow Leopard upgrade on a Mac with MacPorts installed, which I use for Django development, playing WoW and EVE Online. )

The MySQL command line client has an option "--i-am-a-dummy" which turns on "safe updates". The idea is that any update or delete will fail unless there is a WHERE clause - which is a common mistake of people new to this whole SQL thing - and even better, the WHERE clause has to reference a unique key (eg: the primary key of the table ( Read more... )

Okay, so this isn't really MySQL's fault. It's a Django problem. Way back in the day this application that I'm maintaining was written in Django 0.95. I've managed to port the forms and models across to Django 1.0-ish. I've included South so we can do database schema migration (and in fact part of the first batch of fixes was to improve performance ( Read more... )

I'm sure I'm taking this completely out of context:

However, you can enable the NO_AUTO_CREATE_USER SQL mode to prevent GRANT from creating a new user if it would otherwise do so, unless IDENTIFIED BY is given to provide the new user a non-empty password.

Emphasis is mine.