鸟哥的基础学习-习题与答案

There is significant portion of customers which are still using MyISAM when
they come to us, so one of the big questions is when it is feasible to move to
Innodb and when staying on MyISAM is preferred ?

I generally prefer to see Innodb as the main storage engine because it makes
life much simpler in the end for most users – you do not get to deal with
recovering tables on the crash or partially executed statements. Table locks is
no more problem, hot backups are easy, though there are some important things
which we have to consider on case by case basics before recommending the
move.

Is MyISAM used as default or as a choice ?
This is the most
important question to ask upfront. Sometimes MyISAM is there just because it is
default, in other cases this is deliberate choice with system being optimized to
deal with MyISAM limits, for example there is a dedicated slave available for
all long reporting queries. In case MyISAM was chosen not just happened to be it
is important to build the good argument to suggest Innodb.

Application Readiness
Application should be ready to work
with Innodb, for example be ready to deal with deadlocks which can happen with
Innodb even if you do not use transactions, but which are not existent with
MyISAM. QA has to be performed as part of the move.

Performance
Innodb has a lot to offer in terms of
performance – Performance benefits and drawbacks. On the benefits side we
usually see clustering by primary key, caching data, higher concurrency,
background flushes while on the drawbacks side we see significantly large table
size (especially if data size is close to memory size), generally slower writes,
slower blob handling, concurrency issues, problems dealing with very large
number of tables, slow data load and ALTER TABLE and others. Another big one is
COUNT(*) without where clause which is often the show stopper for them move
until it is worked around.

Operations
What is good for MyISAM kills Innodb, such as
copying binary tables between the servers. It is important the team understands
Innodb and knows how to handle it, or be able to learn it. It is also important
to adjust processes as required to work with Innodb. For example binary copy of
one of the databases from the Slave to the dev envinronment works great for
MyISAM but does not work with Innodb. Backup tools like “mysqlhotcopy” does not
work etc. Note Performance also affects Operations aspects a lot – for example
using mysqldump as a backup may well work for MyISAM but will start taking way
too much time to do restore for Innodb. On large scale installations mysqldump
does not work anyway but it may still work for you when you’re running MyISAM
but instantly break upon upgrading to Innodb.

Features
The MyISAM features which forbid moving to Innodb
are typically Full Text Search and RTREE indexes/GIS with Full Text being much
more common. There are workarounds for both of them, including dedicated MyISAM
slave or shadow table but it is important to consider them.

How about Mixing Storage Engines ?
Sure you can mix storage
engines but I suggest you doing is wisely. It complicates operations tasks
(backups, balancing, performance analyzes) as well as it exercises not so common
paths in the MySQL server – in particular Optimizer may have harder time because
costs between storage engines may not be well balanced or replication of mixed
table types which is quite complicated.

I prefer to pick one storage engine (typically Innodb) and when use other
tables when it really gives substantial gains. I would not switch table to
MyISAM because it gives 5% performance improvement but I can perfectly use
MyISAM (or Archive) for logging.

Innodb Needs Tuning
As a final note about MyISAM to Innodb
migration I should mention about Innodb tuning. Innodb needs tuning. Really.
MyISAM for many applications can work well with defaults. I’ve seen hundreds of
GB databases ran with MyISAM with default settings and it worked reasonably.
Innodb needs resources and it will not work well with defaults a lot. Tuning
MyISAM from defaults rarely gives more than 2-3 times gain while it can be as
much as 10-50 times for Innodb tables in particular for write intensive
workloads. Check here
for details.

Note:
As Few people questioned me, I indeed forgot to
clarify the scope here – I’m mainly speaking about OLTP/ Traditional web
applications. for Analytics things are a lot different.