在MySQL 5.1之前的版本中,默认的搜索引擎是MyISAM,从MySQL 5.1之后的版本中,默认的搜索引擎变更为InnoDB。
MyISAM与InnoDB存储引擎的主要特点
InnoDB:
行级锁、事务安全(ACID兼容)、支持外键、不支持FULLTEXT类型的索引(5.6.4以后版本开始支持FULLTEXT类型的索引)。
InnoDB具有事务,支持4个事务隔离级别,回滚,崩溃修复能力和多版本并发的事务安全,包括ACID。
如果应用中需要执行大量的INSERT或UPDATE操作,则应该使用InnoDB,这样可以提高多用户并发操作的性能。
MyISAM:
MyISAM管理非事务表。表级锁、不支持事务和支持全文索引,适合一些CMS内容管理系统作为后台数据库使用,它提供高速存储和检索,以及全文搜索能力。
如果应用中需要执行大量的SELECT查询,那么MyISAM是更好的选择.
Innodb不支持全文索引,如果一定要用的话,最好使用sphinx等搜索引擎。myisam对中文支持的不是很好,不过新版本的Innodb已经支持了
mysql支持三种锁定级别,行级、页级、表级;
MyISAM支持表级锁定,提供与 Oracle 类型一致的不加锁读取(non-locking read in SELECTs)
注意
InnoDB支持行级锁,InnoDB表的行锁也不是绝对的,如果在执行一个SQL语句时MySQL不能确定要扫描的范围,InnoDB表同样会锁全表,注意间隙锁的影响
update table set num=1 where name like “%aaa%”
InnoDB行锁是通过给索引项加锁来实现的,即只有通过索引条件检索数据,InnoDB才使用行级锁,否则将使用表锁。
两种类型最主要的差别就是InnoDB支持事务处理与外键和行级锁。而MyISAM不支持。
MyISAM与InnoDB构成上的区别
1).每个MyISAM在磁盘上存储成三个文件:
第一个文件的名字以表的名字开始,扩展名指出文件类型,.frm文件存储表定义。
第二个文件是数据文件,其扩展名为.MYD (MYData)。
第三个文件是索引文件,其扩展名是.MYI (MYIndex)。
2).基于磁盘的资源是InnoDB表空间数据文件和它的日志文件,InnoDB 表的 大小只受限于操作系统文件的大小,一般为 2GB。
注意:MyISAM表是保存成文件的形式,在跨平台的数据转移中使用MyISAM存储会省去不少的麻烦
InnoDB(索引组织表)使用的聚簇索引、索引就是数据,顺序存储,因此能缓存索引,也能缓存数据
MyISAM(堆组织表)使用的是非聚簇索引、索引和文件分开,随机存储,只能缓存索引。
随着CPU核数的增加,InnoDB的吞吐量反而越好,而MyISAM,其吞吐量几乎没有什么变化,显然,MyISAM的表锁定机制降低了读和写的吞吐量。
MyISAM是一种非事务性的引擎,使得MyISAM引擎的MySQL可以提供高速存储和检索,以及全文搜索能力,适合数据仓库等查询频繁的应用;
InnoDB是事务安全的;事务是一种高级的处理方式,如在一些列增删改中只要哪个出错还可以回滚还原,而MyISAM就不可以了。
MySQL表级锁有两种模式:表共享读锁(Table Read Lock)和表独占写锁(Table Write Lock)。什么意思呢,就是说对MyISAM表进行读操作时,它不会阻塞其他用户对同一表的读请求,但会阻塞对同一表的写操作;而对MyISAM表的写操作,则会阻塞其他用户对同一表的读和写操作。
行级锁在每次获取锁和释放锁的操作需要消耗比表锁更多的资源
在InnoDB两个事务发生死锁的时候,会计算出每个事务影响的行数,然后回滚行数少的那个事务。当锁定的场景中不涉及Innodb的时候,InnoDB是检测不到的。只能依靠锁定超时来解决
注意
InnoDB 中不保存表的具体行数,也就是说,执行select count() from table 时,InnoDB要扫描一遍整个表来计算有多少行,但是MyISAM只要简单的读出保存好的行数即可,但是当count()语句包含where条件时,两种表的操作是一样的。
MyISAM适合:
1). 做很多count 的计算;
2). 插入不频繁,查询非常频繁,如果执行大量的SELECT,MyISAM是更好的选择;
3). 没有事务。
InnoDB适合:
1). 可靠性要求比较高,或者要求事务;
2). 表更新和查询都相当的频繁,并且表锁定的机会比较大的情况指定数据引擎的创建;
3). 如果你的数据执行大量的INSERT或UPDATE,出于性能方面的考虑,应该使用InnoDB表;
注意
DELETE FROM table时,InnoDB不会重新建立表,而是一行一行的 删除;
清空整个表时,InnoDB是一行一行的删除,效率非常慢。MyISAM则会重建表。
LOAD TABLE FROM MASTER操作对InnoDB是不起作用的,解决方法是首先把InnoDB表改成MyISAM表,导入数据后再改成InnoDB表,但是对于使用的额外的InnoDB特性(例如外键)的表不适用。
对于AUTO_INCREMENT类型的字段,InnoDB中必须包含只有该字段的索引,但是在MyISAM表中,可以和其他字段一起建立联合索引。
对于自增长的字段,InnoDB中必须包含只有该字段的索引,但是在MyISAM表中可以和其他字段一起建立联合索引。
InnoDB存储引擎被完全与MySQL服务器整合,InnoDB存储引擎为在主内存中缓存数据和索引而维持它自己的缓冲池。
不需要事务支持(不支持)
并发相对较低(锁定机制问题)
数据修改相对较少(阻塞问题),以读为主
数据一致性要求不是非常高
尽量索引(缓存机制)
调整读写优先级,根据实际需求确保重要操作更优先
启用延迟插入改善大批量写入性能
尽量顺序操作让insert数据都写入到尾部,减少阻塞
分解大的操作,降低单个操作的阻塞时间
降低并发数,某些高并发场景通过应用来进行排队机制
对于相对静态的数据,充分利用Query Cache可以极大的提高访问效率
MyISAM的Count只有在全表扫描的时候特别高效,带有其他条件的count都需要进行实际的数据访问
InnoDB
需要事务支持(具有较好的事务特性)
行级锁定对高并发有很好的适应能力,但需要确保查询是通过索引完成
数据更新较为频繁的场景
数据一致性要求较高
硬件设备内存较大,可以利用InnoDB较好的缓存能力来提高内存利用率,尽可能减少磁盘 IO
主键尽可能小,避免给Secondary index带来过大的空间负担
避免全表扫描,因为会使用表锁
尽可能缓存所有的索引和数据,提高响应速度
在大批量小插入的时候,尽量自己控制事务而不要使用autocommit自动提交
合理设置innodb_flush_log_at_trx_commit参数值,不要过度追求安全性
避免主键更新,因为这会带来大量的数据移动

借鉴用于复习
https://www.cnblogs.com/Jtianlin/p/8954841.html
本文详细对比了MySQL中的MyISAM与InnoDB存储引擎的特点。MyISAM适合大量SELECT查询,提供高速存储和检索及全文搜索能力,而InnoDB支持事务处理、行级锁和外键,适用于频繁更新和高并发的场景。
5544

被折叠的 条评论
为什么被折叠?



