昨晚收到客服MM電話，一用戶反饋數(shù)據(jù)庫響應非常慢，手機收到load異常報警，登上主機后發(fā)現(xiàn)大量sql執(zhí)行非常慢，有的執(zhí)行時間超過了10s
優(yōu)化點一：
| SELECT * FROM `sitevipdb`.`game_shares_buy_list` WHERE price>='2.00′ ORDER BY tran_id DESC LIMIT 10; |
表結構為：
| CREATE TABLE `game_shares_buy_list` (`tran_id` int(10) unsigned NOT NULL AUTO_INCREMENT,`………..'PRIMARY KEY (`tran_id`),KEY `ind_username` (`username`)) ENGINE=InnoDB AUTO_INCREMENT=3144200 DEFAULT CHARSET=utf8; |
執(zhí)行計劃：
| root@127.0.0.1 : sitevipdb 09:10:22> explain SELECT * FROM `sitevipdb`.`game_shares_buy_list` WHERE price>='2.00′ ORDER BY tran_id DESC LIMIT 10;+—-+————-+———————-+——-+—————+———+———+——+——+————-+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+—-+————-+———————-+——-+—————+———+———+——+——+————-+| 1 | SIMPLE | game_shares_buy_list | index | NULL | PRIMARY | 4 | NULL | 10 | Using where |+—-+————-+———————-+——-+—————+———+———+——+——+————-+1 row in set (0.00 sec) |
分析該sql的執(zhí)行計劃，由于tran_id是表的主鍵，所以查詢根據(jù)主鍵降序順序掃描，這樣就可以不用排序，
然后在過濾條件price>2.00的記錄，看上去這個執(zhí)行計劃貌似非常好，如果查詢掃描到了滿足條件的10條記錄，就會停止掃描；
但是這里有個問題，如果表中有大量的記錄是不符合2.00的，意味查詢就需要掃描非常多的記錄，才能找到符合條件的10條：
| root@127.0.0.1 : sitevipdb 09:17:23> select price,count(*) as cnt from `game_shares_buy_list` group by price order by cnt desc limit 10;+——-+——-+| price | cnt |+——-+——-+| 1.75 | 39101 || 1.68 | 38477 || 1.71 | 34869 || 1.66 | 34849 || 1.72 | 34718 || 1.70 | 33996 || 1.76 | 32527 || 1.69 | 27189 || 1.61 | 25694 || 1.25 | 25450 | |
可以看到表中有大量的記錄不是2.00的，所以這個時候不能在根據(jù)主鍵順序掃描，在過濾記錄；
那么是否需要在price建立一個索引：
| root@127.0.0.1 : sitevipdb 09:09:01> select count(*) from `game_shares_buy_list` where price>'2′;+———-+| count(*) |+———-+| 4087 |+———-+root@127.0.0.1 : sitevipdb 09:17:31> select count(*) from `game_shares_buy_list` ;+———-+| count(*) |+———-+| 1572100 | |
從上面price的數(shù)據(jù)分布可以看出，price的分布相對還是比較集中的，如果在price建立索引，mysql也有可能認為由于需要回表的記錄過多，
同時需要額外的排序，而不選擇在price上的索引：
新聞熱點
疑難解答
圖片精選
