When people think of MySQL they normally think of MySQL running across multiple Intel servers running Red Hat, SuSE or Windows. This is great for small and medium sized organizations. However, adding a number of Intel boxes and dealing with heating, electricity, power and storage is not an ideal scenario for larger organizations.

As MySQL grows in popularity, I believe more organizations are

MySQL can be used 64,000 different ways with just about any type of database. Despite this flexibility, here is how I see the growth of MySQL in the database market: Web-based applications are an area of strength for MySQL. MySQL will continue to grow and remain popular in this space.Data Warehousing is the big potential growth area for MySQL. In the next few years it will be very

MySQL excels as a strong solution for web-based solutions. MySQL’s extremely fast read rates and ability to scale horizontally with replication makes MySQL a popular low cost of ownership platform for web-based applications. The next area I expect MySQL to encounter significant growth is in the data warehousing market. MySQL’s fast reads and horizontal scalability makes it a strong

A bunch of (hopefully) self-explanatory slides about new subquery optimizations in MySQL 6.0 is available here (UPDATE: here's a working link). The slides are from this MySQL University session, so there was an audio stream but there were some difficulties with it and it is not available now.

If you miss the audio, the next opportunity to hear about this topic is the New Subquery Optimizations in MySQL 6.0 …

It’s just three weeks now before the 2008 MySQL Conference. Good to see my mug shot on the front page (see screen shot below).

I will still be presenting my session Top 20 DB Design Tips Every Architect Needs to Know, however as a departing MySQL Employee I’ve had to give up the chance to present the “MySQL for Oracle DBA’s Bootcamp” tutorial, content that I developed for MySQL specifically and have already presented three one day seminars in New York, San Francisco and Washington DC.
Update March 26 2008. I should clarify that I notified MySQL as part of my exit items that I would not be able to present the Tutorial. I would very much like to, and being the author of the content I am well qualified, however as this was developed for MySQL and …

It’s just three weeks now before the 2008 MySQL Conference . Good to see my mug shot on the front page (see screen shot below). I will still be presenting my session Top 20 DB Design Tips Every Architect Needs to Know , however as a departing MySQL Employee I’ve had to give up the chance to present the “MySQL for Oracle DBA’s Bootcamp” tutorial, content that I developed for MySQL specifically and have already presented three one day seminars in New York, San Francisco and Washington DC.

I was interested to note that as of this morning, attendee registration numbers for the MySQL User Conference (which O'Reilly co-produces with MySQL) are up 32% over the same period last year. This seems to be a good sign that the community is energized by MySQL's acquisition by Sun.

The conference takes place April 14-17 at the Santa Clara Convention Center. Among other things, we'll be hearing from Jonathan Schwartz, the CEO of Sun, about Sun's open source strategy (presumably including their plans for MySQL), as well as a deep technical program with tracks including Storage Engine Development …

Recently, I noticed a post on Planet MySQL expressing distaste for surrogate keys. Ever since reading it the topic has been bugging me so I thought I would finally break out a defense for surrogate keys.

Really, it comes down to the right tool for the right job. Like The Force, they can be used for both good and evil. The fact is that a surrogate key can be wildly useful and efficient if used in the right context. For instance, this blog uses surrogate keys here and there. I'll be honest, in some cases it may help and hinder. For instance, to maintain uniqueness, my BlogPosts table has an auto incremented primary key. To me, this makes sense. Yes, I …

Twice a year, Sun invites their Sun Fellows, Sun Distinguished Engineers and many Principal Engineers, Sales Engineers and Consultants to an offsite meeting, usually in California and this time in the Chaminade in Santa Cruz. For the first time, we now had MySQLers present — and over 20 of us.

The purpose of the meeting is to share new trends, new technologies, and new ideas across Sun’s wide spectrum spanning everything from the bare metal of the Niagara system through other aspects of system all the way to software.

I was fortunate enough to be given the opportunity to describe MySQL the Product, MySQL the Business and MySQL the Culture, in a long 90 minute day session in front of all the audience. Our Product, Business and Culture were described by a six-headed panel, with Jim Starkey, Jan Kneschke, Michael “Monty” Widenius, Mikael Ronström, Igor Babaev and Serg …

A lot of people seem to spend a lot of effort comparing storage engine in MySQL - chiefly focusing on the difference between MyISAM and InnoDB.

People normally compare:

Feature sets:InnoDB: better durability, transactions, MVCC, foreign key constraints, row-level locking. MyISAM: fulltext, spatial indexes, table-level locking
Run-time performance: (see your favourite benchmark)

But few compare actual storage space usage. As this is very important to our application, I decided to run some tests.

I'm testing here with a realistic-sized table for our application (we partition data into daily partitions and spread them across many servers anyway, so this is just a small piece). We currently use MyISAM, and this is a typical table with approximately 4 million rows.

I can't dump the schema or content of this table here for confidentiality reasons, but it has: