你应该把MYISAM迁移到INNODB吗？
原文链接：http://www.mysqlperformanceblog.com/2009/01/12/should-you-move-from-myisam-to-innodb/
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 ?
有很大一部分客户在找到我们的时候，还是用的MYISAM引擎，所以一个重大的问题就是，什么时候适合迁移到INNODB比较好，什么时候保持MYISAM比较好？
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.
通常情况下我更愿意用INNODB作为主要的存储引擎，因为它最终让大多数的用户生活更加简单了--你不需要去处理由于表损坏或者部分执行的语句带来的恢复表。表锁已经不是问题，热备也很简单，但是在推荐引擎迁移之前我们还是有一些重要的问题需要具体问题具体分析。
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.
MYISAM是默认的还是特意选择的？ 这是放在前面的最重要的问题。有时候使用MYISAM仅仅因为它是默认存储引擎，在另外一些情况下对于解决MYISAM的限制做了优化的系统，这是有意的选择，比如为了所有报表的大查询而专用的slave。如果MYISAM不仅仅是被偶然选中，那么给建议使用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.
应用快捷 应用程序应该为使用INNODB做好了准备，比如在INNODB里处理死锁，即使你没有使用事务，但这在MYISAM里是不存在的。QA作为引擎迁移的一部分必须被执行。
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.
性能 INNODB在性能方面做了很多提高--性能的优缺点。在优点方面我们经常看到的有通过主键聚集，数据缓存，高并发，后台刷新，而在缺点方面我们看到表大小显著增大（尤其在数据大小接近内存大小），写入缓慢，bolb处理缓慢，并发的问题，处理表数量非常大时的问题，加载数据缓慢，ALTER TABLE等等。另外一个大的问题是不带WHERE条件的COUNT(*)经常很慢，在它被解决之前这常常是显示慢的原因。
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.
操作 这方面MYISAM优于INNODB，比如在不同的服务器之间拷贝二进制表。理解INNODB和知道怎么使用它或者能学会它对于团队来说很重要。和INNODB一起使用时根据需要调整处理方法也很重要。比如从slave上拷贝一个数据库到开发环境在MYISAM下工作得很好，但是在INNODB下却不行。像“mysqlhotcopy”这样的备份工具对INNODB也不起作用。注意性能也影响操作的很多方面--比如用MYSQLDUMP备份MYISAM会很好，但是将花费很多时间来还原成INNODB。在大型设备上当你使用MYISAM时mysqldump还能继续工作，但是一旦升级到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.
功能 典型的阻止从MYISAM转移到INNODB的功能特点是全文搜索和使用全文搜索的RTREE索引/GIS。有变通的办法来处理这2点，包括专用的MYISAM SALVE或者影像表，但是考虑到这些是很重要的。
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.
存储引擎混存怎么样？ 当然你可以混合存储引擎,但我建议你明智的做这些。它不但使操作任务（备份，负载均衡，性能分析）复杂了，而且也不是MYSQL SERVER常见的部署方案--尤其是优化器可能很难工作得好，因为不同存储引擎之间的开销可能不能很好的均衡，还有混合模式的的复制变得复杂了很多。
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)，当其他表性能确实有实质性的提高时，再选择别的存储引擎。我不会因为5%的性能提高而把引擎转换成MYISAM，但是我完全可以使用MYISAM（或ARCHIVE）做日志记录。
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.
INNODB 需要调优 关于MYISAM向INNODB转移的最后一点，我觉得应该提一下INNODB的调优。INNODB需要调优，真的！MYISAM作为默认引擎对很多的应用能够工作得很好，我已经见到过上百G的数据库跑在MYISAM的默认配置上，而且跑得很好。INNODB需要更多的资源而且在默认配置下工作得不好。把MYISAM从默认参数调优很少需要2-3次的调整，但是INNODB表最多需要10-50次的调整，尤其是在高负载的场景下。点这里获取详细信息
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.
备注：要不是有一些人问起，我在这里确实忘记阐明这篇文章的作用范围--我主要是讲述OLTP/传统的网页应用。为分析系统的有很多的不同之处。