什么是表引擎
我们看到的表结构,它的本质是数据在硬盘中的存储。根据不同的特性,数据的存储方式不同。比如:对于每一条数据,在硬盘中它是怎么存储的,怎么压缩的,怎么建立索引和优化的,它的读取和写入是怎么实现的。这些完整的一条路径,我们称之为表引擎。
选择的依据
选择的依据,是我们的需求,我们的需求很大程度上决定我们的选择。有的时候,我们的习惯决策着这个过程。这里,我们关注一下方面:
并发性,同一时间支持的写入和读取特性;
安全性,物理存储结构,异常发生时数据的是否可靠;
事务性,数据执行的颗粒,以及提供的定义原子操作的特性;
查询优化,这里我们指查询缓存和索引;
在开发上,我们主要关注:(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。