标签：
最近新到项目上，算是帮忙，遇见性能测试。
测试要求其实不高，现在是单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 *
另外就是，在对列数很多的表做查询的时候，尽量不要使用*，这个还是有效率影响的，只列出来你需要的列，效率会更高。
写得比较凌乱，多数是一些建议，思路，具体的内容，在网上，书上，很容易找到。
标签：
原文地址：http://my.oschina.net/u/1778412/blog/483739
