MySQL只能做小项目？是时候说几句公允话了！
我上学那会，许多人对 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 也更具用武之地。
因此，第二个问题也是可以解决的。
据我理解，互联网公司使用 MySQL 还是比力多的，传统软件公司，大概会更喜爱 Oracle 等数据库。
不外话说回来，云运算，也是将来一个标的目的。
更多MySQL相关技术文章，请拜访MySQL教程栏目停止学习！
以上就是MySQL只能做小项目？是时候说几句公正话了！的具体内容，更多请关注百分百源码网其它相关文章！
