前言

  • 大部分情况下， InnoDB 是最正确的选择。
  • MySQL 5.5 版本将 InnoDB 作为默认的存储引擎。

除非需要用到某些 InnoDB 不具备的特性，并且没有其他办法可代替，否则应该优先选择 InnoDB 引擎。 如：如果用到全文索引，建议是 InnoDB + Sphinx 的组合，而不是使用 MyISAM。

使用不同的存储引擎，考量因素：

  • 事务：
    • InnoDB 是目前最稳定且经过验证的选择。
    • 若不需要事务，并且主要是 SELECT 和 INSERT ，可使用 MyISAM。如：日志型应用。
  • 备份：
    • 若需要在线备份，建议选择 InnoDB。
  • 崩溃恢复：
    • MyISAM 崩溃后发送损坏的概率比 InnoDB 高的多，而且恢复速度也慢。
    • 一般推荐选择 InnoDB 引擎。
  • 特有的特性：
    • 基于应用所需特性选择，如：MyISAM 支持地理空间搜索。

应用场景

日志型应用

  • 场景：
    • 记录一台电话交换机的每一通电话日志到 MySQL。
    • 通过 Apache 的 mod_log_sql 模块将网站访问信息记录到表中。
  • 推荐：MyISAM 或 Archive 存储适合该类，特点：开销低，插入数据非常快。
    • 不足：若实现日志分析报表，查询的 SQL 可能导致插入效率明显降低。
    • 解决方案：
      • 方法1：利于 MySQL 内置复制方案，复制到备库，在备库执行消耗时间和 CPU 的查询。主库仅用于高效的插入工作
      • 方法2：利用分表的方式，如：按日、月形式记录，负载均衡或负载拆分

只读或大部分情况下只读的表

  • 适合场景：读多写少，如：一些固定性配置（省市区数据等）
  • 推荐：若不介意 MyISAM 崩溃情况，可考虑使用 MyISAM 引擎。
  • 风险：崩溃引起的数据丢失
    • 原理：MyISAM 将数据写到内存中，待系统定期将数据刷到硬盘中。

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

重要：不要轻易相信 “MyISAM 比 InnoDB 快”的经验之谈。

在实际应用中，InnoDB 的速度有时候可让 MyISAM 望尘莫及，尤其使用到聚簇索引，或者将需要访问的数据放入到内存的应用。 若设计如上应用，MyISAM 在起初没问题，但应用压力上升，可能迅速恶化。各种锁争用，崩溃后的数据丢失问题也随之而来。

订单处理

  • 重要数据，需要考虑事务，推荐使用 InnoDB 引擎。

电子公告板和主题讨论论坛

  • 主要注意使用过 select count(*) from table 的情况
  • 数据量大小、引擎不一性能不一

CD-ROM 应用

  • 若需要发布一个基于 CD-ROM 或 DVD-ROM 存储 MySQL 数据文件，可考虑 MyISAM 表或 MyISAM 压缩表。
  • 特点：表数据之间互相隔离，可使用不同介质上相互拷贝。MyISAM 压缩表比未压缩表要节约很多空间，但压缩表是只读的。

大数据量

  • 大数据量的参考：创建或管理很多 InnoDB 数据库数量月 3~5TB 的内容，或者更大；单机的量，而非一个分片的量。
  • 若使用 MyISAM，数据崩溃后恢复是一个噩梦。
  • 若数据量增长到 10TB 以上级别，需要考虑建立数据仓库。Infobright 是 MySQL 数仓最成功的解决方案。
    • 有些不适合使用 Infobright，却可能适合 TokuDB。