前言之所以寫這篇文章，是源於以前看過的關於sql語句優化的帖子，裡面明確提到了在sql語句中不要使用 * 來做查詢，就像下麵的規則中說的但是中國有句姥話叫“盡信書不如無書”，難道在sql查詢語句中使用星號就真的慢的要死，難道加索引也不行？帶著這些個疑問，我進行了一些測試。結果發現，江湖傳說未必真 ...

前言

之所以寫這篇文章，是源於以前看過的關於sql語句優化的帖子，裡面明確提到了在sql語句中不要使用 * 來做查詢，就像下麵的規則中說的

2、儘量避免使用select *，返回無用的欄位會降低查詢效率。如下：

SELECT * FROM t 

優化方式：使用具體的欄位代替*，只返回使用到的欄位。

但是中國有句姥話叫“盡信書不如無書”，難道在sql查詢語句中使用星號就真的慢的要死，難道加索引也不行？帶著這些個疑問，我進行了一些測試。結果發現，江湖傳說未必真的靠得住。那具體測試情況是咋樣的呢？下麵且聽我給各位看官慢慢分解。

　　事先聲明，本文是拋磚文，只進行測試，不做原理分析（要不然篇幅太長，各位看官估計要看睡著了）。本文的一切測試均以實際測試數據為準，拒絕假大空。

測試環境準備

我這次測試的系統環境如下：

Win10系統
Mysql5.7.26 64位版本，使用預設的InnoDB存儲引擎

　　然後我準備了一張tb_item表，用來存放測試數據，數據是我跟朋友要的一些商品信息數據。

　　下圖是tb_item表的結構

　　tb_item表中的部分數據

　　我將從以下幾個方面去進行測試：

count查詢
聯表查詢
分頁查詢

　　好，閑話不多說，馬上開整。

一．count查詢

在count查詢操作中，又分為兩種情況，不帶where條件的count查詢，和帶where條件的count查詢。那我們就依次來測試一下。

1. 不帶where條件的count查詢

　　我們先來測試一下統計整個表的記錄數。首先給大家劇透一下，tb_item表一共有300萬條數據。執行 SELECT COUNT(*) FROM tb_item，結果如下圖所示

　　可以看到，查詢時間是7秒多。如果是配置一般的機器，估計會更慢。顯然，統計整張表的數據量，使用星號貌似是不行的。

　　那有沒有辦法可以優化一下呢？當然有啊，而且我都給大家測試好了。在tb_item表中有一個 status 欄位，不知道大家註意到了沒有

　　我們發現，這個欄位的長度才占一個varchar。那如果我們修改一下剛纔的sql，改成

　　SELECT COUNT(STATUS) FROM tb_item

　　又會如何呢？我們執行一下這條sql，看一下結果

　　可以看到，這次的查詢時間是4秒多，快了將近一半。

　　如果我們給 status 欄位加個索引，結果又會怎樣呢？那我們就加個索引試試。執行

　　CREATE INDEX idx_tb_item_status ON tb_item(STATUS)

　　然後我們再執行一下 SELECT COUNT(STATUS) FROM tb_item，結果如下圖

　　這次的查詢時間是0.9秒，不到1秒。

　　從一開始的7秒多到現在的不到1秒，查詢時間縮短了85%。這個優化結果真是爽的一批啊。

2. 帶where條件的count查詢

　　現在我們再試一下使用星號執行帶where條件的查詢操作會是個什麼情況。我們簡單一些，就查詢價格小於1000塊錢的商品數據。

　　執行 SELECT COUNT(*) FROM tb_item t WHERE t.price<1000，結果如下圖

　　查詢時間是6秒多。那我們給price欄位加上索引後，再看看是個什麼情況。執行下麵的sql給price欄位加索引

　　CREATE index idx_tb_item_price ON tb_item(price)

　　然後再次執行 SELECT COUNT(*) FROM tb_item t WHERE t.price<1000，結果如下圖

　　各位朋友，你們沒有看錯，加了索引之後，查詢時間確實只有0.28秒。這查詢效率提升了 99% 啊，簡直爽得不要不要的。

　　那如果我們將星號換成長度只有一個varchar的 status 欄位，情況又會是咋樣的呢？我們來試一下

　　是的，你沒看錯，這次查詢又花了6秒多的時間。也就是說，price欄位的索引失效了。

　　看來帶where條件的情況下，直接指定具體欄位還不如直接用星號呢。

　　剛纔我們只測試了帶一個查詢條件的情況，下麵我們再來試試帶多個查詢條件的情況。這次我查詢price大於1000，sellerid（品牌代碼）欄位是oppo的數據。預期查詢時間小於1秒

　　查詢時間6秒多，不能接受。那我先給sellerid欄位上個索引再試試

　　查詢時間5秒，還是太慢。那就上個組合索引，給price和sellerid欄位加個組合索引再試試。

　　這次的查詢時間是1秒多，雖然已經算不錯了，但是還是沒有達到我們預期的結果。而且我總不能增加一個查詢條件，就改一次索引吧？

　　所以，對於這種百萬級別數據的多條件查詢的情況，最好的解決辦法就是上一個數據檢索系統，比如lucence或者elastic search，然後把數據導入到數據檢索系統中，讓它幫mysql完成數據的條件檢索，Mysql只提供數據的詳情查詢服務。而且，像es這樣的系統還帶有分詞功能，可以輕鬆通過關鍵詞實現數據的檢索。這比使用mysql的like操作來檢索數據，效率不知道要高多少倍。所以，專業的事情還是交給專業的系統去乾。別跟我說公司沒錢，上不起es。數據量達到300w的業務，你跟我說沒錢？