mysql 何时使用myisam，何时使用innodb

1、MyISAM管理非事务表。它提供高速存储和检索，以及全文搜索能力。如果应用中需要执行大量的SELECT查询，那么MyISAM是更好的选择。

2、InnoDB用于事务处理应用程序，具有众多特性，包括ACID事务支持。如果应用中需要执行大量的INSERT或UPDATE *** 作，则应该使用InnoDB，这样可以提高多用户并发 *** 作的性能。

扩展资料：

MyISAM和InnoDB主要区别：

1、MyISAM是非事务安全型的，而InnoDB是事务安全型的。

2、MyISAM锁的粒度是表级，而InnoDB支持行级锁定。

3、MyISAM支持全文类型索引，而InnoDB不支持全文索引。

4、MyISAM相对简单，所以在效率上要优于InnoDB，小型应用可以考虑使用MyISAM。

5、MyISAM表是保存成文件的形式，在跨平台的数据转移中使用MyISAM存储会省去不少麻烦。

6、InnoDB表比MyISAM表更安全，可以在保证数据不会丢失的情况下，切换非事务表到事务表。

参考资料来源：百度百科—— MyISAM 

参考资料来源：百度百科—— InnoDB

由于等待和 Buffer Pool 的各种 latch 相关，而且 delete *** 作本身会产生大量脏数据，那会不会跟刷脏页 *** 作相关呢？我们看下 SQL 被 kill 的量和刷脏页的量之间的关系。

发现每秒刷脏页的量和 SQL 被 kill 的量的曲线有点相近，看着刷脏页的量挺大的，但是每秒 delete 的 TPS 又不是很高，为啥这么低的 TPS 会让刷脏页频率抖动以及 SQL 执行变慢呢？曾经换过不同批次的机器，发现问题依旧，并没有改善，说明并不是机器本身的问题。继续浏览 buffer pool 相关的监控指标，像是发现新大陆一样的发现了一个异常指标脏页比例达到了快 90% ！！！太吓人了！！！为啥脏页比例会达到 90% 呢，无非就是刷脏页的速度跟不上产生的速度，要么就是 IO 能力不行，要么就是产生脏页的速度过快，要么就是内存池太小，导致 Buffer Pool 被脏页占满。那么这个脏页比例达到快 90% 会有什么问题呢？

innodb_max_dirty_pages_pct_lwm 表示的是当脏页比例达到该参数表示的低水位时候，刷脏线程就开始预刷脏来控制脏页比例，避免达到innodb_max_dirty_pages_pct 。刷脏页的最大 IO 能力是受 innodb_io_capacity 和 innodb_io_capacity_max 控制。生产上我们将 innodb_max_dirty_pages_pct_lwm 设置成了50当脏页比例大于 innodb_max_dirty_pages_pct 时候，InnoDB 会进行非常激烈的刷脏页 *** 作，但是由于 DELETE *** 作还是在进行，脏页产生的速度还是非常快，刷脏页的速度还是跟不上脏页产生的速度。为了避免脏页比例进一步扩大，更新将会被堵塞，从而导致 DELETE 执行变慢，直至被 KILL。发现问题之后，根据我们之前的假设，有三种解决方案：1 调大 io_capacity ，但是由于主机是多实例部署，IO 占用已经比较高，PASS。2 降低脏页产生速度，也就是调低 DELETE 速度，因为数据产生的速度很快，为了避免删除跟不上插入的速度，也被 PASS。3 调大 Buffer Pool，可以容纳更多的脏页。说干就干，得益于 MySQL 57 的在线调整 Buffer Pool，立马将 Buffer Pool Size 扩了一倍，效果非常显著。

脏页比例立马下降，被 kill 的 SQL 也下降了。平均 SQL rt 下降很多。

总结

得益于 MySQL 的开源，很多错误都可以直接确认到对应的代码，大致定位到问题发生的地方，给问题排查带来了很多方便。同时对 MySQL buffer pool 的命中率以及脏页比例也要多多关注，对 SQL 的性能都有很大的影响。

基本的差别为：

MyISAM类型不支持事务处理, MyISAM类型的表强调的是性能，其执行数度比InnoDB类型更快，但是不提供事务支持，而InnoDB提供事务支持已经外部键等高级数据库功能。这样就可以根据数据表不同的用处是用不同的存储类型。

另外，MyISAM类型的二进制数据文件可以在不同 *** 作系统中迁移。也就是可以直接从Windows系统拷贝到linux系统中使用。

InnoDB 是 MySQL 上第一个提供外键约束的引擎，除了提供事务处理外，InnoDB 还支持行锁，提供和 Oracle 一样的一致性的不加锁读取，能增加并发读的用户数量并提高性能，不会增加锁的数量。

InnoDB 的设计目标是处理大容量数据时最大化性能，它的 CPU 利用率是其他所有基于磁盘的关系数据库引擎中最有效率的。

InnoDB 是一套放在 MySQL 后台的完整数据库系统，InnoDB 有它自己的缓冲池，能缓冲数据和索引，InnoDB 还把数据和索引存放在表空间里面，可能包含好几个文件，这和 MyISAM 表完全不同，在 MyISAM 中，表被存放在单独的文件中，InnoDB 表的大小只受限于 *** 作系统文件的大小，一般为 2GB。

MyIASM是IASM表的新版本，有如下扩展：

二进制层次的可移植性。

NULL列索引。

对变长行比ISAM表有更少的碎片。

支持大文件。

更好的索引压缩。

更好的键吗统计分布。

更好和更快的auto_increment处理。

以下是一些细节和具体实现的差别：

1InnoDB不支持FULLTEXT类型的索引。

2InnoDB 中不保存表的具体行数，也就是说，执行select count() from table时，InnoDB要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。注意的是，当count()语句包含 where条件时，两种表的 *** 作是一样的。

3对于AUTO_INCREMENT类型的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中，可以和其他字段一起建立联合索引。

4DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。

5LOAD TABLE FROM MASTER *** 作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性（例如外键）的表不适用。

另外，InnoDB表的行锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，例如update table set num=1 where name like “%aaa%”

任何一种表都不是万能的，只用恰当的针对业务类型来选择合适的表类型，才能最大的发挥MySQL的性能优势。

1 研究结论

1)InnoDB占用磁盘空间比MyISAM大，MyISAM存储数据可节省空间12%，存储索引可节省95%;

2)InnoDB对空闲存储空间的使用不优。

研究发现，MyISAM可大量节省磁盘空间，特别是对索引的存储上，优势巨大，这对大型Mysql数据库的数据表和索引的物理设计，具有较大的指导意义。

2 研究对象及获得的数据

Mysql版本：5126-rc-community

研究对象为创建的一个表，mytable3，初始为InnoDB类型。有54万行非重复数据(用随机函数产生)，两个索引。

从实验数据可以看出，表类型alter为MyISAM后，所占磁盘空间仅8MB，为InnoDB的4%。而且随着表类型改回InnoDB，InnoDB表空间被迫扩充120MB，达到1034MB，以支持该表数据的回迁。

以上就是关于mysql 何时使用myisam，何时使用innodb全部的内容，包括:mysql 何时使用myisam，何时使用innodb、innodb 数据库中的脏页数据是怎么产生的、innodb和myisam的区别等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！