MySQL 只能做小项目？松哥要说几句公道话！

一时失言乱红尘 2022-01-09 10:51 246阅读 0赞

松哥上学那会，很多人对 MySQL 有一些偏见，偏见主要集中在以下几方面：

1.  MySQL 不支持事务（事实上 MyISAM 有表锁，但是效率比较低）
2.  MySQL 存储的数据量比较小，适合小项目，大项目还是得上 Oracle、DB2 等

这么多年过去了，松哥自己在开发中一直是以 MySQL 为主，我觉得我有必要说两句公道话了。

# 公道话 #

## 第一个问题 ##

关于第一个不支持事务的问题，这有一定的历史原因。MySQL 从设计之初，存储引擎就是可插拔的，允许公司或者个人按照自己的需求定义自己的存储引擎（当然，普通的公司或者个人其实是没有这个实力的）。MySQL 自研的使用较广的存储引擎是 MyISAM ，MyISAM 支持表锁，不支持行锁，所以在处理高并发写操作时效率要低一些，另外 MyISAM 也不支持外键（虽然现在实际项目中外键已经用的比较少了）。

但是这个问题并非无解。这就不得不说 MySQL 中另外一个大名鼎鼎的存储引擎 InnoDB 了。

InnoDB 存储引擎是由一家位于芬兰赫尔辛基的名为 Innobase Oy 的公司开发的，InnoDB 存储引擎的历史甚至比 MySQL 还要悠久。

InnoDB 刚刚开发的时侯，就是作为一个完整的数据库来开发的，因此功能很完备。开发出来之后，创始人是想将这个数据库卖掉的，但是没有找到买家。

后来 MySQL2.0 推出后，这种可插拔的存储引擎吸引了 Innobase Oy 公司创始人 Heikki Tuuri 的注意，在和 MySQL 沟通之后，决定将 InnoDB 作为一个存储引擎引入到 MySQL 中，MySQL 虽然支持 InnoDB ，但是实际上还是主推自家的 MyISAM。

但是 InnoDB 实在太优秀了，最终在 2006 年的时侯，成功吸引到大魔王 Oracle 的注意，大手一挥，就把 InnoDB 收购了。

MySQL 主推自家的 MyISAM ，日子过得也很惨淡，最终在 2008 年被 sun 公司以 10 亿美元拿下，这个操作巩固了 sun 在开源领域的领袖的地位，可是一直以来 sun 公司的变现能力都比较弱，最终 sun 自己在 2009 年被 Oracle 收入囊中。那会松哥还在读高中，某一天吃午饭的时侯，餐厅的电视机上播放央视的午间新闻，看到了这条消息，现在还有一些印象。

Oracle 收购 sun 之后，InnoDB 和 MySQL 就都成了 Oracle 的产品了，这下整合就变得非常容易了，在后来发布的版本中，InnoDB 慢慢就成为了 MySQL 的默认存储引擎。在最新的 MySQL8 中，元数据表也使用了 InnoDB 作为存储引擎。

InnoDB 存储引擎主要有如下特点：

1.  支持事务
2.  支持 4 个级别的事务隔离
3.  支持多版本读
4.  支持行级锁
5.  读写阻塞与事务隔离级别相关
6.  支持缓存，既能缓存索引，也能缓存数据
7.  整个表和主键以 Cluster 方式存储，组成一颗平衡树
8.  …

当然也不是说 InnoDB 一定就是好的，在实际开发中，还是要根据具体的场景来选择到底是使用 InnoDB 还是 MyISAM 。

所以第一个问题不攻自破。

## 第二个问题 ##

第二个问题确实是一个硬伤。

你要是拿 MySQL 和 Oracle 比，肯定是要差一点点感觉。毕竟一个免费一个收费，而且收费的还很贵。但是这个问题并非无解。

相信很多小伙伴都听过国内很多大厂都使用了 MySQL 来存储数据。大厂用 MySQL ，是因为他们有能力研发出自己的存储引擎，小厂一般没有这个实力，没法去研发出自己的存储引擎，但是 Oracle 又用不起，那么怎么办呢？

这几年兴起的分布式数据库中间件刚好可以很好的解决这个问题。Java 领域，类似的工具很多，例如 Sharding-JDBC 、MyCat 等，通过这些工具，可以很好的实现数据库分库分表，以及数据表的动态扩展、读写分离、分布式事务解决等。有了这些工具，极大的提高了 MySQL 的应用场景。

另一方面，近些年流行微服务，这不是单纯的炒概念，微服务架构将一个大的项目拆分成很多个小的微服务，各个微服务处理自己很小的一部分事情，这更符合人类分工协作的特点。在微服务架构中，我们对大表的需求、对多表联合查询的需求都会有所降低，MySQL 也更具用武之地。

因此，第二个问题也是可以解决的。