php进阶之数据库设计/ 选择合适的表引擎
什么是表引擎
我们看到的表结构，它的本质是数据在硬盘中的存储。根据不同的特性，数据的存储方式不同。比如：对于每一条数据，在硬盘中它是怎么存储的，怎么压缩的，怎么建立索引和优化的，它的读取和写入是怎么实现的。这些完整的一条路径，我们称之为表引擎。
选择的依据
选择的依据，是我们的需求，我们的需求很大程度上决定我们的选择。有的时候，我们的习惯决策着这个过程。这里，我们关注一下方面：
并发性，同一时间支持的写入和读取特性；
安全性，物理存储结构，异常发生时数据的是否可靠；
事务性，数据执行的颗粒，以及提供的定义原子操作的特性；
查询优化，这里我们指查询缓存和索引；
在开发上，我们主要关注：（1,3,4），在运维层面，我们关注（2）。
在表的选择上，最常用的是如下：
MyIsam
Innodb
Memory（Heap）
从案例开始
现在我们要做一个留言板，我们发现这个留言板可能有几种情况：
有很多人同时留言，同时，查看留言的人也很多；
留言的人很少，每天查看留言的人非常多；
我们的功能有留言奖励，每天前10个留言的，会有积分奖励；
我们的留言板有点像实时聊天器，对性能要求和实时性要求非常高；
MYSIAM
在5.0的时代，这个表是使用得非常普遍的，我了解的Discuz就是使用这种表。它的优势：查询速度，被很多人看重。我们看看它的一些特点：
理论上存储无限制（与操作系统的文件系统有关）
存在text/blob全文索引
索引缓存
数据压缩
低存储空间和低内存占用
高速写入
查询缓存
串行写入时，全表锁（读和写）
不支持事务
集群支持
B-Tree索引
create table a_myisam (.....) ENGINE = MYISAM;
以上特性，我们看到MyIsam主要是为查询而设计的，也是最初大家做数据存储时考虑的东西。
InnoDB 从5.1开始，InnoDB慢慢发展起来，并且成为重要数据的存储引擎。它的特点如下：
有限制的存储
索引缓存
支持事务
查询缓存
写入行锁
B-Tree索引
create table a_myisam (.....) ENGINE = InnoDB;
InnoDB更加稳定和成熟，也为更多需求提供解决方案。
Memory
查询速度快
mysql重启后丢失
B-Tree和HASH索引
仅仅是为了快，小量数据。
A：很多人同时留言，看留言的人也很多
这意味着什么？我们的写入速度要够快且写入不影响读取。或者，我们可以并行写入。这种情况，如果我们选择MyIsam，写入量的增加会导致全表上锁，以至于读取时，要等待锁的释放；那么，显然，MyIsam会造成表性能瓶颈。这种情况，我们选择Innodb。理由如下：
Innodb写入时，锁为行锁；不影响其它写入，影响少量读（有可能大量）；
Innodb的查询性能理论上比Myisam稍差，但是非常小，可忽略；
B：留言的人很少，每天查看留言的人非常多
这个时候，选择MyIsam，没有什么问题。（读/写比较高）
C：我们的功能有留言奖励，每天前10个留言的，会有积分奖励
我们需要一些原子级别的操作，也就是在判断某条留言是前10名的时候，就将它标记，而这个标记需要原子级的：标记的过程中不允许别人查询和写入（全表锁）。这是什么意思？由于我们的操作是没有严格的前后顺序的，计算机的CPU运算分片本质是串行的。假设这个时候你有两条命令：
查询是否前10个
增加积分
假设现在已经有9个条留言了，那么这个时候来了两个请求，都查询自己是否是前10个。第一个用户查到自己是第10个，然后在它要执行第二步的时候，第11个用户来了，他也查询自己是第10个，如果没有保护机制，那么第11个也被认为是满足条件，他也会被加分。
如何实现？
一般情况下我们会增加一个字段来做标记，这个字段假设为：lock，那么更新的时候保证这个中间是没有其它操作的。我们称之为事务。
start
select ... from table where lock = 0 for update;
update table set lock = 1;
commit
D：我们的留言板有点像实时聊天器，对性能要求和实时性要求非常高
呵呵，这个不用说了，使用innodb和memory都可以。一般我们使用内存存储，会把它当做K-V来使用，根据设计的情况来选择。（不过，业内很少时候，内存的存储一般都会选择Memcache和Redis）。
总结一下
如果读/写 比很大的话，假设这个尺度为10，那么，就使用myisam（写入并发小的情况）
如果需要事务的支持，使用innodb
如果需要对并发性（写入）有要求的话，使用innodb
其它情况，可以根据实际场景选择
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。互联网+时代，时刻要保持学习，携手千锋PHP,Dream It Possible。