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 真的没那么弱。