InnoDB引擎
(1)这是MySQL5.5之后的默认存储引擎,它提供了对ACID事务的支持。所谓ACID事务指:
Automicity(原子性),指事务是一个不可分割的工作单元,事务中的操作要么都发生,要么都不发生。
Consistency(一致性),事务前后数据的完整性必须保持一致。
Isolation(隔离性),事务的隔离性是多个用户并发访问数据库时,数据库为每一个用户开启的事务,不能被其他事务的操作数据所干扰,多个并发事务之间要相互隔离。
Durability(持久性),持久性指事务一旦被提交,它对数据库中数据的改变就是永久的,即使之后数据库发生故障也不应对其有影响。
(2)它还实现了SQL标准的四种隔离级别。
Read uncommitted(读未提交),在这种隔离级别下,select语句不加锁,可能读到不一致的数据,即脏读。这是一致性最差的隔离级别。
Read committed(读已提交),可避免脏读,但在互联网高并发量场景下几乎不会使用以上两种隔离级别。
Repeatable read(可重复读),MySQL默认隔离级别,可避免脏读、不可重复读的发生。
SeriaIizable(串行化),可避免脏读、不可重复读和幻读的发生。
以上四种隔离级别最高的是 Serializable 级别,最低的是 Read uncommitted 级别,级别越高,执行效率就越低。如Serializable 这样的级别,就是以锁表 的方式(类似于Java多线程中的锁)使得其他的线程只能在锁外等待,所以平时选用何种隔离级别应该根据实际情况。
(3)提供了行级锁和外键约束,设计目标就是处理大容量数据库系统。
什么场景适合用InnoDB?
1.当需要使用数据库的事务时。
2.由于锁的粒度更小,写操作不会锁定全表,所以在并发量较大的场景选InnoDB可以提升效率。
MyIASM引擎
这是MySQL5.5以前的默认存储引擎。没有对数据库事务的支持,也不支持行级锁和外键约束。
因此在执行insert(插入)和update(更新)语句时,要锁住整张表,使效率降低。
什么场景适合用MyIASM?
MyISAM引擎中保存了表的行数,因此当执行SELECT COUNT(*) FROM TABLE时,可以直接读取已经保存好的值而不需要进行全表扫描。
所以,如果表的读操作远远多于写操作,而且不需要数据库事务的支持,可以将MyIASM作为数据库引擎的首选。
两者的总体区别
- InnoDB是事务安全的,MyIASM是非事务安全的。
- InnoDB锁的粒度比MyIASM的粒度更小,InnoDB是行级锁,MyIASM是表级锁。
- MyIASM相对简单,效率上优于InnoDB,因此小型系统可采用MyIASM。
- InnoDB不支持全文索引(老版本),MyIASM支持全文索引。
InnoDB在1.2.x版本之后(即MySQL 5.6 之后),就开始支持全文索引了。