有些表的数据用于编制类目或者分列清单(如工作岗位，竞拍、不动产等)，这种应场景是典型的读多写少的业务。如果不介意MyISAM香港服务器的崩溃恢复问题，选用MyISA引擎是合适的。不过不要低估崩溃恢复问题的重要性，有些存储引擎不会保证将数据安全地写人到磁盘中，而许多用户实际上并不清楚这样有多大的风险(MyISAM只将数写到内存中，然后等待操作系统定期将数据刷出到磁盘上)。

        一个值得推荐的方式，是在性能测试环境模拟真实的环境，运行应用，然后拔下电源模拟崩溃测试。对崩溃恢复的第一手测试经验 是无价之宝，可以避免真的碰到崩溃时手足无措。

        不要轻易相信“MyISAM 比InnoDB快”之类的经验之谈，这个结论往往不是绝对的。在很多我们已知的场景中，InnoDB的速度都可以让MyISAM望尘莫及，尤其是使用到聚簇索引，或者需要访向的数据都可以放人内存的应用。在本书后续章节，读者可以了解更多影响存储引擎性能的因素(如数据大小、1/O请求量、主键还是二级索引等)以及这些因素对应用的影响。

        当设计上述类型的应用时，建议采用InnoDB。MyISAM 引擎在一开始可能没有任何问面，但随着应用压力的上升，则可能迅速恶化。各种锁争用、崩溃后的数据丢失等问题都会随之而来。

订单处理

        如果涉及订单处理，那么支持事务就是必要选项。半完成的订单是无法用来吸引用户另外一个重要的考意点是存储引擎对外键的支持情况。InnoDB 是订单处理类应用的最佳选择。