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 *

另外就是，在對列數不少的表作查詢的時候，儘可能不要使用*，這個仍是有效率影響的，只列出來你須要的列，效率會更高。

寫得比較凌亂，多數是一些建議，思路，具體的內容，在網上，書上，很容易找到。