MySQL引擎的区别

哎，你问我InnoDB和MyISAM如何选择？ 这两个确实是MySQL中最常遇到的存储引擎，而且差异巨大。
我给大家总结一下，都是我在项目中遇到的坑或者实际使用的经验。

上周，一位客户问我为什么他们的电子商务系统卡住了。
后来发现数据库都是MyISAM。
想想看，当他们建立一个订单系统时，他们需要交易和外键。
MyISAM并不直接支持它，所以最终他们必须完全重构它。
我对此印象特别深刻。

核心差异应记住以下几点：
1 事务支持：InnoDB是刚需。
财务和订单就不用谈了。
必须满足 ACID。
我曾经在一个支付系统上工作，如果没有InnoDB，就不可能改变它。
MyISAM就别想了，根本不支持，数据丢失了你可能都不知道。

2 锁定机制：InnoDB使用行级锁。
写入时，只有几行被锁定。
当并发量较高时，这尤其有用。
2 02 3 年上海的一个项目，写操作较多的时候，InnoDB比MyISAM快了不止一点点。
但MyISAM使用表级锁定。
如果写稍微大一点的表，就会整个表被锁，用户会骂。
记得有一次测试，MyISAM在写入几十万条数据时，后台卡住了两个小时。

3 索引和性能：InnoDB不支持FULLTEXT全文索引，需要全文检索注意。
但MyISAM有它。
我以前有一个新闻网站，用MyISAM加FULLTEXT来搜索，速度惊人。
不过，InnoDB 现在支持它，从版本 5 .6 开始，具体取决于您使用的 MySQL 版本。

4 外键：InnoDB支持外键，可以直接在数据库中进行数据关联，没有任何麻烦。
MyISAM根本没有这个功能。
你必须在代码中自己处理，这样特别容易出错。
我曾经使用过MyISAM，忘记在应用层添加检查。
结果数据乱了，花了我很长时间。

5 崩溃恢复：InnoDB有事务日志（redolog），出了问题可以回滚，数据非常安全。
MyISAM就惨了。
如果崩溃的话，桌子可能会被直接损坏，必须手动修复。
我看到同事们为此工作了很长时间。

适用场景直接说：

必须使用InnoDB的情况：
需要交易（这个基本涵盖了所有业务系统）
高并发写入（如订单、闪购）
要求数据完整性（需要外键约束）
表更新和查询频繁（锁概率高，InnoDB行级锁优势明显）

MyISAM可以使用的场景：
多读少写（如日志表、配置表）
需要快速的COUNT()（MyISAM直接统计表行数，而InnoDB必须扫描整个表）
全文搜索（例如内容网站）
无事务需求，容易担心（临时表什么的）
其他需要注意的事项：

默认引擎：MySQL现在默认为InnoDB，但早期版本默认为MyISAM。
您可以使用显示引擎； 查看支持的引擎，SHOW VARIABLES LIKE '%storage_engine%'； 看看默认的。

性能权衡：InnoDB擅长复杂查询和高并发写入，但单线程读取可能不如MyISAM快。
MyISAM在简单查询和静态数据场景下高效，但在高并发写入时崩溃。

混合使用：可以在一个数据库中同时使用两种引擎，例如事务表使用InnoDB，日志表使用MyISAM，但必须付费注意备份和恢复的兼容性。

总结建议：

优先考虑InnoDB：除非你坚持使用MyISAM的全文索引或者COUNT()性能，否则默认使用InnoDB是正确的，特别是在需要事务或者高并发的情况下。

不要碰MyISAM的事务和外键：如果在设计阶段发现需要事务或者外键，MyISAM就会直接PASS，否则以后再改就惨了。

实际测试验证：特定场景下，建议使用sysbench什么的来运行测试。
我测试了一张2 02 2 年的电商订单表，InnoDB的速度比MyISAM快一倍，而且随着数据量的增加差距就更大了。

无论如何，你必须弄清楚。
如今，系统设计中几年不使用InnoDB的情况已经非常罕见了。
如果您有任何具体问题，我会详细与您交谈。

MySql的存储引擎扫盲

不客气地说，MySQL存储引擎的选择对于系统性能和稳定性至关重要。
其实很简单。
不同的存储引擎适合不同的场景。
我们先来说说最重要的事情。
InnoDB是默认引擎，支持事务和行级锁，适合对高并发和强数据完整性要求的业务，例如金融系统。
还有一点是MyISAM适合读多写少的场景，比如日志分析，因为它不支持事务和行级锁，但是并发性能很高。
还有另一个关键细节。
虽然MEMORY引擎读写速度很快，但数据存储在内存中，一旦断电就会丢失。

一开始我以为所有业务都适合InnoDB，后来发现错了。
比如对于日志分析系统，MyISAM就比较适合。
等等，还有一件事。
像MRG_MYISAM这样的合并表引擎虽然可以合并多个MyISAM表，但是其并发性能有限，一般用于数据分区。

所以，在选择存储引擎时，必须考虑以下因素：事务和一致性要求、读写比、数据持久性以及特殊功能要求。
例如，如果您需要全文搜索，MyISAM或InnoDB（5 .6 +）是不错的选择。
在资源消耗方面，InnoDB的崩溃恢复和MVCC都会占用较多的内存，需要进行适当的配置。

最后，让我提醒您一个容易陷入的陷阱，那就是混合动力发动机的风险。
例如InnoDB表和MyISAM表之间的跨引擎事务不支持ACID，所以设计时要小心。
总之，可以根据业务需求、数据规模、运维能力等综合评估，找到最合适的存储引擎。
您认为，存储引擎选择时还有哪些其他因素也很重要？