mysql数据库调优

最近新到项目上，算是帮忙，碰见性能测试。

测试要求其实不高，如今是单mysql数据库，未分表，四千万数据，四百毫秒，上的压力是一千一百多tps，可是，动态的只占到了百分之二十左右，也就是两百左右的tps吧。服务器仍是比较牛逼的，我看到了十几个cpu线程，估计超过一百G内存吧。

大致状况如上。

鄙人以前没优化过mysql，其实，是没调优过sql，只读过部分sql执行的原理，数据库的结构啥的，日常写sql和设计表的时候有些注意，实战调优经验为零，之前就算调了，没测试过，也白搭，此次算是逮到便宜了。

废话说了很多，说说具体的问题吧。

首先，是如何分析sql慢的具体缘由。

在mysql下，数据库引擎要注意，咱们用的是innodb，行锁。

其实，我主要用到的，就是explain，这个东西能够帮助我分析sql的具体执行状况。

我主要看的，仍是行数那一列，看看它执行的时候遍历了多少行。这个数量直接会影响到速度。固然，其它的也颇有用，不是看的太懂，半猜着来的。

通常的方法，就是给查询的不少的那个列加索引。

主要是给，where的条件，join的条件，另外就是，这里不用都加，索引是有代价的。给主要的加上，在执行sql的时候，达到减小遍历行数的目的就行了

我本机测试，四千万的数据的表，插入一条数据须要不到两百毫秒，这是在有一个normal btree索引的时候是这样的，因此，代价仍是蛮大的。

按理说，这个数量级实际上是须要分表的。根据个人此次的经验，一千万左右的时候，就该分了，不然，各方面是有影响的。

另外就是优化sql。

主要思路是sql对具体的语句的执行顺序，尽可能让限制性的sql可以将数据范围变小，这样，在各类join和where的时候速度才能快点。

排序，group by这种操做，尽可能放在最后执行，由于这种操做比较耗时，须要便利当前的全部数据。

另外就是，在行间的select尽可能不要使用，若是能够的话，换成join，由于行间的sql会根据行数执行。

应该老是限制返回的结果数量。若是返回的结果数量，若是返回过多的话，不管怎么优化，都会很慢，你能够尝试对四千万的表select *

另外就是，在对列数不少的表作查询的时候，尽可能不要使用*，这个仍是有效率影响的，只列出来你须要的列，效率会更高。

写得比较凌乱，多数是一些建议，思路，具体的内容，在网上，书上，很容易找到。