面经复盘之「存储引擎适用场景」的思考——从“区别”到“作用”到“场景”

通常会以「区别」作为引子：InnoDB和MyISAM的区别是什么？

应试选手发言：

• 简单来说，相较于InnoDB而言，MyISAM不支持事务，不支持行锁，不支持外键（等等）。

然后发问：那他们各自的适用场景分别是什么？

同样的，需要一个思考方向。

而前面的“引子”就已经提供了一个很好的思考方向。

毕竟 适用场景就意味着，他为什么适合这个，他为什么不适合那个，为什么他更适合这个

这是一个比较，所以我们可以直接从MyISAM与InnoDB的区别入手。

从「事务」来思考

我们知道MyISAM不支持事务，那么就可以从事务来入手：**事务的作用是什么？**保证数据库的一致性和完整性。

并且我们知道InnoDB为了保证事务的ACID，废了极大功夫（锁机制、日志系统），这意味着对数据库的每一次操作都需要进行相应的维护，相较MyISAM而言是一个“重量级”引擎。

那么就意味，对数据库一致性和完整性要求不高的场景可以考虑选择MyISAM。比如多读少写的场景。

从「锁机制」来思考

我们知道InnoDB支持行锁、表锁、意向锁和mvcc，而MyISAM仅支持表锁，并且锁的设计主要也是为了保证事务的ACID，但是行锁的设计则是为了进一步提高系统的并发度，因此，空有表锁意味着在高并发场景下的效率非常底下。所以相较于InnoDB而言，MyISAM更适用于低并发的场景，同样的也适用于多读少写的场景。

从「外键」来思考

外键的作用其实也是为了保证数据库的一致性和完整性，因此同「事务」。

或许也可以说其适用于表之间关联性不高的结构，但是现在的系统多是在代码端来实现实体之间的关联，而非数据库层面。

仅从这上述来看，可以看出MyISAM更适用于

• 对数据库一致性和完整性要求不高的场景（可靠性要求不高）
• 多读少写的场景（想到读写分离）
• 低并发的场景

与之相对的，InnoDB则更适合于

• 高并发
• 可靠性高
• 写多读少