mysql的几种存储引擎 mysql常见的三种存储引擎

InnoDB支持事务。
ACID保证数据的可靠性。
行级块提高了并发性。
外键约束维护关联表。

默认为旧版本的MyISAM。
表级写阻塞。
阅读速度快，报告方便。
没有国外交易密钥。

内存 存储内存。
表级键与MyISAM相同。
临时表用途广泛。
不稳定。
重启期间丢失。

InnoDB适合多种事务。
MyISAM 是读密集型的。
MEMORY 临时数据。

自己掂量一下。

mysql中的engine=innodb;是什么意思？

MySQL中重要的数据库存储引擎

说实话，刚入行的时候，在选择这三个存储引擎的时候，我走了很多捷径。
以InnoDB为例。
我记得2 005 年左右，我们公司的电商项目就是专门做InnoDB的。
在系统并发量增加的同时，表级锁直接导致数据库损坏。
后来使用了InnoDB行级锁，性能立刻得到提升。
有趣的是，虽然InnoDB外键约束很方便，但在编写代码时必须小心SQL语句的嵌套关系，否则死锁警告会很可怕。
曾经有一个案例，一个事务更新了三个表的数据，由于顺序错误而被阻塞。

看看MyISAM，我负责旧的数据仓库系统，那个人就是MyISAM。
虽然它不支持事务，但其性能非常糟糕，读取较多，写入较少。
最神奇的是全文索引。
当时，搜索引擎还处于起步阶段。
该系统多年来一直依赖MyISAM全文索引的支持。
然而教训是惨痛的——有一天服务器突然宕机，恢复数据的时候发现MyISAM日志丢失了，还有几天的增量。
这场战斗……幸好只是测试环境。

最后，我们来谈谈内存。
这件事给我印象最深的是报表缓存。
当时有一个实时报告，是第二次更新的。
它采用MEMORY存储机制，将结果集直接传输到内存中。
查询速度比直接表扫描至少快十倍。
不过这个东西有一个问题——服务器重启后，缓存被清空，需要重新计算，所以只适合非必要的数据。
我记得在测试过程中我立即重新启动了生产机器以避免出现问题。
结果，记者团队陷入疯狂，最终只能依靠备份和恢复...
这三种类型的引擎之间没有绝对的选择。
我有一个朋友在金融系统工作，没有使用InnoDB事务。
他说他们的业务逻辑很简单，不会写错SQL。
结果，他们遇到了无数的陷阱。
粗略来说，还是要看场景，必须结合数据敏感度、读写比、可靠性等要求。