Our Santa Clara/San Francisco training went great - 100% of survey respondents said they would recommend the same course to a friend.  I'm pleased to announce that such an opportunity exists - our next training location will be New York City on October 30, 2009.

We've booked a training venue in the financial district of Manhattan (90 Broad Street New York, NY 10004), and it seems like a great opportunity to switch from using hotels to teaching in real classrooms.  This means that every student will have a (Linux) computer provided, and the instructor will have a whiteboard to be able to scribble.

Some other changes:

…

Use mysqladmin utility to find MySQL server\'s uptime. Run the following command from command line.

If you have an empty data folder or you want to initialize/reinitialize MySQL server from scratch (possibly after dropping all existing databases) then use these instructions.

To show indexes on a MySQL table execute any of the commands mentioned in the tutorial in a MySQL client.

You can speed up index scans if you periodically perform a void ALTER TABLE operation, which causes MySQL to rebuild the table.

If you have deleted a large no. of records from a table or if you have made many changes to a table with variables length rows, you should run OPTIMIZE TABLE command.

UNION is used to combine the result from multiple SELECT statements into a single result set. By default, when it is applied to more than one queries, returns unique result sets only. UNION ALL on the other hand returns all rows in the result sets.

Save the date - October 14th, 3pm Paris & Berlin, 2pm London, 4pm Jerusalem  -  for this free live webinar where you'll have a chance to ask questions to our experts.

This webinar focuses on how ZFS, SSDs and the Open Storage line of products from Sun are changing the rules in the database storage industry. You will learn how to increase data security, scalability, and reduce the price/performance ratio with these technologies. This webinar includes ZFS best practises for databases backup and performance.

To register, click here.

Following up on Mark Callaghan's blog post on how useful query cache is nowadays.

One has to say it aloud at last: let's kill it. Say, in 5.4.
It's useless on modern hardware anyway, and if you look at re-designing it, it turns out there is need for multiple solutions, since no single one performs well in all caching workloads.
What would it give our users? One less gotcha-like feature in the server that they need to learn, learn to forget. It will open up a niche for third-party projects to contribute. And the core server development team will have one less thing to worry about.

I generally use the following MySQL INFORMATION_SCHEMA (I_S) query to Calculate Your MySQL Database Size. This query and most others that access the MySQL INFORMATION_SCHEMA can be very slow to execute because they are not real tables and are not governed by physical data, memory buffers and indexes for example but rather internal MySQL data structures.

Mark Leith indicates in his post on innodb_stats_on_metadata that Innodb performs 8 random(ish) dives in to the index, when anybody accesses any of SHOW TABLE STATUS, SHOW INDEX, INFORMATION_SCHEMA.TABLES,INFORMATION_SCHEMA.STATISTICS for InnoDB tables. This can have an effect on performance, especially with a large number of Innodb tables, and a poor ratio of innodb_buffer_pool_size to disk data+index footprint.

What is even more …