单机数据库的不可能三角

正如经济政策的不可能三角“不可能同时实现资本流动自由，货币政策的独立性和汇率的稳定”那样，单机数据库也有一个不可能三角，那就是：①持久化 ②事务隔离 ③高性能，三者不可兼得。

为什么不可能

1. 持久化需要每一次写数据都要落到磁盘上，宕机再启动以后，数据库可以自动修复。如果只要求这一条，很好实现。
2. 事务隔离需要每一次会话（session）的事务都拥有自己的数据库版本：既要多个并行的事务相互之间不会写到对方的虚拟数据库上（读提交），又要不能读到对方的虚拟数据库上（可重复读），还要在一个事务内不能读到别的事务已经提交的新增的数据（幻读），终极需求则是完全串行化——我的读 session 不结束，你就不能读。这个需求和持久化需求结合以后，会大幅增加日志管理的复杂度，但仍然是可控的。
3. 读写都要尽量地快：单独实现也很快，内存数据库嘛（如 Redis），但是加上持久化和事务隔离，就很难做了——需要对前两项进行妥协。

MySQL 选择了哪两个？

首先，MySQL 选择了持久化：失去人性，失去很多；失去持久化，失去一切。没有持久化能力的核心数据库就做不了核心数据库，这一条是所有磁盘数据库的刚需，完全无法舍弃。

然后，MySQL 选择了一部分高性能：MyISAM 就是为了快速读写而创造的，早期 MySQL 在低配 PC 机上就有不错的性能。后来更高级的 InnoDB 出现了，小数据量时它的读取性能不如 MyISAM，写性能更是彻底拉胯，但是在面对大数据量场景时，读性能非常强，还能提供很多后端程序员梦寐以求的高级功能（例如丰富的索引），承担了大部分互联网核心数据库的角色。

最后，MySQL 将事务隔离拆成了几个级别，任君挑选：你要强事务隔离，性能就差；你能接受弱事务隔离，性能就强。你说无事务隔离？那你用 MySQL 干什么，Redis 它不香吗。

所以 MySQL 其实选择了 持久化*1 + 高性能*0.8 + 事务隔离*0.5，算下来，还赚了 0.3。

不过，从 MySQL 也可以看出，“数据库的不可能三角”并不是完全互斥的，是可以相互妥协的。

在开始细数分布式数据库之前，我们先看一个非分布式的数据库性能提升方案——读写分离，主从同步。