选择MyISAM
原文：InnoDB还是MyISAM 再谈MySQL存储引擎的选择
两种类型最主要的差别就是Innodb 支持事务处理与外键和行级锁.而MyISAM不支持.所以MyISAM往往就容易被人认为只适合在小项目中使用。
从运维角度来说看，要达到需求：99.9%的稳定性，方便的扩展性和高可用性来说的话，MyISAM绝对是我的首选。
原因如下：
1、首先我目前平台上承载的大部分项目是读多写少的项目，而MyISAM的读性能是比Innodb强不少的。
2、MyISAM的索引和数据是分开的，并且索引是有压缩的，内存使用率就对应提高了不少。能加载更多索引，而Innodb是索引和数据是紧密捆绑的，没有使用压缩从而会造成Innodb比MyISAM体积庞大不小。
3、从平台角度来说，经常隔1，2个月就会发生应用开发人员不小心update一个表where写的范围不对，导致这个表没法正常用了，这个时候MyISAM的优越性就体现出来了，随便从当天拷贝的压缩包取出对应表的文件，随便放到一个数据库目录下，然后dump成sql再导回到主库，并把对应的binlog补上。如果是Innodb，恐怕不可能有这么快速度，别和我说让Innodb定期用导出xxx.sql机制备份，因为我平台上最小的一个数据库实例的数据量基本都是几十G大小。
4、从我接触的应用逻辑来说，select count(*) 和order by 是最频繁的，大概能占了整个sql总语句的60%以上的操作，而这种操作Innodb其实也是会锁表的，很多人以为Innodb是行级锁，那个只是where对它主键是有效，非主键的都会锁全表的。
5、还有就是经常有很多应用部门需要我给他们定期某些表的数据，MyISAM的话很方便，只要发给他们对应那表的frm.MYD,MYI的文件，让他们自己在对应版本的数据库启动就行，而Innodb就需要导出xxx.sql了，因为光给别人文件，受字典数据文件的影响，对方是无法使用的。
6、如果和MyISAM比insert写操作的话，Innodb还达不到MyISAM的写性能，如果是针对基于索引的update操作，虽然MyISAM可能会逊色Innodb,但是那么高并发的写，从库能否追的上也是一个问题，还不如通过多实例分库分表架构来解决。
7、如果是用MyISAM的话，merge引擎可以大大加快应用部门的开发速度，他们只要对这个merge表做一些select count(*)操作，非常适合大项目总量约几亿的rows某一类型(如日志，调查统计)的业务表。
当然Innodb也不是绝对不用，用事务的项目如模拟炒股项目，我就是用Innodb的，活跃用户20多万时候，也是很轻松应付了，因此我个人也是很喜欢Innodb的，只是如果从数据库平台应用出发，我还是会首选MyISAM。
另外，可能有人会说你MyISAM无法抗太多写操作，但是我可以通过架构来弥补，说个我现有用的数据库平台容量：主从数据总量在几百T以上，每天十多亿 pv的动态页面，还有几个大项目是通过数据接口方式调用未算进pv总数，(其中包括一个大项目因为初期memcached没部署,导致单台数据库每天处理 9千万的查询)。而我的整体数据库服务器平均负载都在0.5-1左右。
选择InnoDB
原文：InnoDB还是MyISAM 再谈MySQL存储引擎的选择
MyISAM 是MySQL中默认的存储引擎，一般来说不是有太多人关心这个东西。决定使用什么样的存储引擎是一个很tricky的事情，但是还是值我们去研究一下，这里的文章只考虑 MyISAM 和InnoDB这两个，因为这两个是最常见的。
下面先让我们回答一些问题：
◆你的数据库有外键吗？
◆你需要事务支持吗？
◆你需要全文索引吗？
◆你经常使用什么样的查询模式？
◆你的数据有多大？
思考上面这些问题可以让你找到合适的方向，但那并不是绝对的。如果你需要事务处理或是外键，那么InnoDB 可能是比较好的方式。如果你需要全文索引，那么通常来说 MyISAM是好的选择，因为这是系统内建的，然而，我们其实并不会经常地去测试两百万行记录。所以，就算是慢一点，我们可以通过使用Sphinx从InnoDB中获得全文索引。
数据的大小，是一个影响你选择什么样存储引擎的重要因素，大尺寸的数据集趋向于选择InnoDB方式，因为其支持事务处理和故障恢复。数据库的在小决定了故障恢复的时间长短，InnoDB可以利用事务日志进行数据恢复，这会比较快。而MyISAM可能会需要几个小时甚至几天来干这些事，InnoDB只需要几分钟。
您操作数据库表的习惯可能也会是一个对性能影响很大的因素。比如： COUNT() 在 MyISAM 表中会非常快，而在InnoDB 表下可能会很痛苦。而主键查询则在InnoDB下会相当相当的快，但需要小心的是如果我们的主键太长了也会导致性能问题。大批的inserts 语句在MyISAM下会快一些，但是updates 在InnoDB 下会更快一些——尤其在并发量大的时候。
所以，到底你检使用哪一个呢？根据经验来看，如果是一些小型的应用或项目，那么MyISAM 也许会更适合。当然，在大型的环境下使用MyISAM 也会有很大成功的时候，但却不总是这样的。如果你正在计划使用一个超大数据量的项目，而且需要事务处理或外键支持，那么你真的应该直接使用InnoDB方式。但需要记住InnoDB 的表需要更多的内存和存储，转换100GB 的MyISAM 表到InnoDB 表可能会让你有非常坏的体验。
混合使用
原文：PHP与MySQL学习笔记8：重要概念与设计Web数据库
1、存储引擎
MySQL支持许多不同的“存储引擎”，也叫作“表格类型”。每个表可是使用不同的存储引擎，而且可以轻松地对它们进行转换。
创建表时可以选择一个表格类型：
CREATE TABLE table TYPE = type....
修改表类型：
alter table orders type = innodb;
1）MyISAM，默认类型
它基于传统的ISAM类型，Indexed Sequential Access Method（有索引的顺序访问方法）的缩写，它是存储记录和文件的标准方法。
MyISAM特点：
MyISAM具有检查和修复表格的大多数工具，表格可以被压缩，支持全文搜索。但是它们不是事务安全的，也不支持外键。
2）InnoDB
该类型表是事务安全的，也就是说，它提供了 COMMIT 和 ROLLBACK功能。InnoDB支持外键。 虽然比MyISAM表要慢些，但是如果应用程序需要一个事务安全的存储引擎，建议使用。
注：在大多数Web应用程序中，通常都会使用MyISAM或InnoDB表格或者二者的结合。
**3）MEMORY **（以前的 HEAP）
该类型表，存储在内存中，表的索引是哈希分布的。
MEMORY表格运行速度非常快，但是如果发生崩溃，数据将丢失。
建议：MEMORY表格适合保存临时或者派生的数据，应该在CREATE TABLE语句中指定MAX_ROWS，否则这些表可能吞噬所有内存。同样，它们不能加入BLOB、TEXT或AUTO INCREMENT列。
4）MERGE
这些表允许你为了查询目的，把MyISAM表的集合作为一个单个表。因此，你可在某些操作系统中，避开最大文件大小限制。
5）ARCHIVE
这些表保存了大量数据，但是只有少量脚注（footprint）。这种类型的表只支持INSERT 和SELECT 查询。不支持DELETE、UPDATE 和 REPLACE。此外，也不使用索引。
6）CSV
这些表保存在服务器的单个文件中，它包含用逗号隔离的数据。
可以方便地用Excel等第三方工具打开。
建议：
当对一个表格使用大量的SELECT 和 INSERT 语句（或者二者结合）时，应该使用MyISAM 表格，因为在执行这两种命令时，MyISAM是最快的。对于很多Web程序（例如分类）来说，MyISAM是最佳选择。如果需要全文搜索功能，也应该使用MyISAM功能。
当事务非常重要（例如存储财务数据），或在INSERT 和 SELECT 语句是交错执行的情况下（例如在线的消息栏或论坛系统），应该使用 InnoDB。InnoDB在MySQL5.6版本中好像支持全文索引了。
2、事务
事务是确保数据库一致的机制，尤其是在发生错误或服务器崩溃情况下确保数据库一致的机制。
事务是一个或一系列的查询，这些查询可以保证能够在数据库中作为一个整体全部执行或者全部不执行。这样，数据库才能在无论事务是否完成的情况下保持一致状态。
比如，银行转账，比如保证从一个账户减少和另一个账户增加的操作完整完成。
ACID原则，就是描述事务安全性的4个需求：
Atomicity（原子性）---一个事务必须是原子性的，它必须是作为一个整体完全执行或者完全不执行。
Consistency（一致性）---一个 事务必须能够使数据库处于一致的状态。
Isoltion（孤立性）---未完全完成的 事务不能被数据库的其他用户所见，也就是说，在事务完全完成之前，它们都是孤立的。
Durability（持续性）---一旦写入到数据库后，事务必须是永久的而且持续的。
注意：一个事务被永久地写入到数据库中称作该事务被提交了。一个没有写入到数据库中的事务（因此数据库将状态重置到事务开始之前的状态）称作事务被回滚了。
3、关系数据库
关系数据库代替普通文件的优点：
1）关系数据库比普通文件的数据访问速度更快。
2）关系数据库更容易查询并提取满足特定条件的数据。
3）关系数据库具有专门的内置机制处理并发访问。
4）关系数据库可以提供对数据的随机访问
5）关系数据库具有内置的权限系统。
4、关系数据库的一些基本概念
1）关系数据库由“关系”组成，这些关系通常称为“表格”
2）列
“列”又叫做“域”或者“属性”
每一列都有一个唯一的名称，和一个相关的数据类型。
3）行
每一行具有相同的格式，也具有相同的属性。行也叫“记录”。
4）值
每个值必须与该列定义的数据类型相同。
5）键
我们必须有一个能够识别每一个特定记录的方法。
表中的标志列成为“键”或“主键”。
数据库由多个表组成，可以使用键作为表格之间的引用。
6）模式
数据库整套表格的完整设计称为数据库的“模式”。它是数据库的设计蓝图。
一个模式应该显示表格及表格的列、各个表的主键和外键。
可以包含示例数据来解析这些数据的含义。
7）关系
关系数据库中有3种基本的关系类型，一对一、一对多、多对多。
4、设计Web数据库
知道什么时候需要一个新表，以及需要哪些键，需要掌握很高的技巧。但是在大多数情况下，我们可以遵循一些基本的原则。
1）考虑实际建模的对象，现实世界对应的对象
2）避免冗余数据
冗余数据将导致两个主要问题：
a. 空间的浪费
b. 数据更新的不一致，数据的完整性将被破坏。（修改、插入和删除时容易导致）
c. 使用原子列值：每一行的每个属性只存储一个数据。
如果我们想在格子里存多个数据值，其实相当于创建了一个表中表，这样系统就不能只计算匹配字段了，而必须分析每个属性值，看系统中是否包含一个匹配。所以，看情况而定吧。
d. 选择有意义的键
e. 考虑需要询问数据库的问题，想一想我们希望数据库回答什么问题，然后确认数据库中是否已经包含所有需要的数据，并且在表之间要有适当的关联。
f. 避免多个空属性的设计。
数据库里有很多空值，很糟糕。首先，浪费空间。其次，在统计列总量或对其他数值列应用计算函数时可能导致错误。还有，当用户看到表中一部分为空时。也很迷惑，他们也不知道是否因为该属性是无关的，还是数据库中有错误，或者是数据尚未输入。
5、表类型总结
1）描述现实世界对象的简单表
2）描述两个现实世界对象的多对多关系的关联表。
6、Web数据库的架构
通常，Web服务器软件，PHP引擎和数据库服务器都在同一台机器上运行。但是数据库服务器在另外一台机器上运行也很常见，这样是出于安全性、提高性能以及负载均衡的原因。
随着应用程序在大小和复杂度上不断增加，我们可能会将PHP应用程序分成不同的层，通常，包括与MySQL交互的数据库层、包含了应用程序的业务逻辑成、管理HTML输出的表示层。