I was about to buy Oracle, but chose MySQL instead (and saveed big $$$)
I'm a DBA for a mid-sized manufacturing company. We were about to upgrade our SQL Server to Oracle 10g, which was going to set ups back a lot of money. I had been experimenting with MySQL and bought this helpful book to give me a better understanding of how to make it run fast. I really liked the case studies, because they cover a lot of different senarios. To make long story short, I was able to convert the SQL Server database to MySQL, and things have been going great.
64 Terabytes of table space!
Many of you might be tempted to go with the free MySQL, instead of possibly paying big bucks to Oracle or IBM for their databases. But what may have been holding you back could be a worry that when you go with MySQL, you are on your own. Unless you are already well versed with it, are there pitfalls in the implementation of table design or tuning that render the choice of MySQL a false economy?
It's a reasonable worry. Schneider does well here to disabuse you of that notion. He addresses both issues.
On the subject of table design, the advice is clear. Actually, it seems that the discussion is broadly applicable to any SQL/relational implementation. If you already know some SQL, you won't feel that MySQL is some weird variant. Which speaks well of its designers.
Most of the book, however, deals with tuning aspects. Now here, you'll probably have to learn new things. Each SQL implementation seems to have specific tuning characteristics. There is little standardisation here across implementations. As what I hope is a reasonable guess, check out the sections on improving the efficiency of searches (ie. queries). This may be the most important thing to optimise in many applications.
In passing, let me make one remark about MySQL's InnoDB data storage engine. It can hold a table space of as much as 64 Terabytes! For the vast majority of you, this should be adequate addressing. And it's a rejoinder to competitors who say MySQL is limited.
(2 reviews)
