Mysql真的没那么弱

1. 前言

Mysql，作为目前最为流行的OLTP数据库之一，各行各业应用非常普遍，也深受广大用户的青睐，这主要因为其开源、简单、灵活和高效等特性。

然而，现实中，很多同学对其有一定程度的误解，认为Mysql远没有商用库那么强大，例如：有说Mysql太弱，join的表不能超过几个；也有说，Mysql太弱，数据量太多或上亿就应付不来了，等等说法。当今，类似这种观点比较常见，尤其是性能方面，相比其他商用库来说，使用Mysql时对用户要求更苛刻一点，或对技术的要求可能更高一些，比如：相同的SQL语句，在同样的硬件条件和数据环境下，有时在Oracle中能很快或较短时间内出结果，但在Mysql中性能却差强人意，用户等很长时间，甚至等一天也不出结果，这种情况，往往是因为对Mysql的使用不当所致。

虽然早在2000年左右，本人就于某互联网公司第一次接触Mysql，因为在此之前，本人一直使用Oracle等商用库，最初也觉得Mysql有些简单、粗糙和单薄。在后续的工作中，虽然也经常会接触到Mysql，但对其印象基本没太大改变，认为其很难作为关键角色承担大型高负载的关键系统。直到数年前，本人主导参与研发一个大型系统，并最后成功上线和正常运行。研发过程中，通过对Mysql进行精细调整和优化，最终，运行于一台小机上的Mysql，独自承担来自全国各地用户的访问和使用，而且，显得游刃有余。关键是，这个系统的数据量达亿级和TB级，而且业务逻辑比较复杂，常见多张表做join的操作，既有实时操作，也有汇聚操作。至此，对Mysql的印象大为改观。

坦率的讲，整体来说，与其他数据库相比，Mysql或许有不足之处，但对典型的OLTP业务，Mysql却是毫不逊色，甚至某些方面超越其他数据库。

下面，我们就从性能优化的角度，通过一个案例，来支撑上述观点

2. 数据环境

2.1. 硬件环境（本地虚机）

CPU：2

内存：4G

硬盘：40G

2.2. 软件环境

OS：Centos6.8

Mysql：Mysql5.7

2.3. 数据环境

2.4. 操作

3. 优化前

3.1. 运行情况

反映查询一晚上没有出来结果。因为不是生产库，本人也大概测了下，只是没等那么久，几秒钟没出结果就终止了，因为，这已经是不正常的表现，跑SQL前看了下执行计划，已基本确定这个SQL性能有很大问题。

3.2. 执行计划

4. 优化后

4.1. 运行情况

优化后，实际运行SQL，0~20ms出结果。

4.2. 执行计划

4.3. 问题分析解决

1）优化前分析

先看优化前的执行计划，从中可以看到，Mysql首先全表扫描了crs表，且没有任何过滤条件，通过这一个节点，对一个OLTP操作来讲，初步判断会存在问题。举个例子，就像我们从一本几千页的书里查找某个章节内容，我们没必要从头到尾的把这本几千页的书通读一遍，因为这样效率太低，我们只需要从目录里发现要查找的章节对应的页码，直接就可以找到和阅读这个章节的内容。这里也一样，这个对crs表全表扫描的操作与上面的例子很类似。尤其是，我们看这个SQL语句，其中，表tch上有个查询条件，这个查询条件没有充分利用，我们又查看了数据结构，这个查询条件相应的字段上并没有任何索引，这应该就是问题所在。

2）解决问题

既然我们已发现问题，那就在表tch的字段t_nm上创建一个索引。

3）优化后分析

问题解决后，我们再看看创建索引后的执行计划，从第一个节点看到，Mysql首先通过新创建的索引（idx_t_nm）读取和过滤了表tch的数据，然后，再将其送到后面的节点。至此，基本可以断定，问题已经得以解决。最后，在笔记本上虚机里的Mysql库中进行了验证，优化后的SQL跑到了0~20ms。

5. 结论

Mysql是一款优秀的数据库产品，其简单、灵活、高效且开源，或许，某些方面还存在一定欠缺，但就其在OLTP业务领域的性能表现，不会比其他数据库差，甚至有些方面，相比其他数据库，还存在很大优势。所以，Mysql真的没那么弱。