前言
之所以寫這篇文章，是源於以前看過的關於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的業務，你跟我說沒錢？
二．聯表查詢
剛才我們測試了在count查詢操作中使用星號的情況，但是都是針對tb_item這一張表的操作。在實際的業務中，更多的是進行聯表查詢的操作。其中一個典型的業務場景，就是字典代碼聯表查詢。比如在tb_item表中有一個sellerid字段，如下圖
我們使用group by 加distinct關鍵字，看一下這個字段都有些什么內容
可以看出來，這都是些品牌的英文或者漢語拼音。那樣的話，我們就可以創建一張品牌信息表tb_seller_info，用來存放品牌的字典碼和名稱。tb_seller_info表的表結構如下圖
下圖是表中的數據
有了這張表，我們就可以做聯表查詢了。首先我們先來測試一下聯表count查詢tb_item表中“小米”公司的產品數據。執行下面的sql
SELECT COUNT(*) FROM tb_item t INNER JOIN tb_seller_info si ON t.sellerid=si.sellerid WHERE si.sellername='小米'
結果如下圖
查詢時間是2秒。現在，我們給tb_item表中的sellerid字段加個索引，再測試一下
可以看到，這次查詢只用了0.35秒。提升效果十分地明顯。
如果我們把星號換成某個具體的字段，比如id字段，又是什么情況呢？我們試一下
可以看到，查詢時間和使用星號的情況差不多。
那如果我們不做count查詢，而是查詢具體的數據呢？
這一下查詢時間就變成了將近7秒。OMG。我們得繼續想辦法優化了。我們先試試給tb_item表的sellerid字段加個索引試試。
可以看到，查詢時間是6秒多，還是不理想。那么我們把星號換成查詢id字段再試試
嘿，只查詢id字段，竟然不到1秒就搞定了。各位親們，看到這個，你們有沒有想到什么？是不是覺得在id字段上建個hash索引，然后再搞個子查詢，就OK了？說實話，我也想這樣干。但是理想很美好，現實卻很蛋疼。因為mysql5.7默認的InnoDB存儲引擎不支持創建hash類型的索引。
那有人可能會說了，用那個MEMORY存儲引擎啊，那個支持創建hash類型的索引。那如果我告訴你，這個存儲引擎是非事務安全的，你還想用嗎？
那么，我們就真的一點辦法都沒有了嗎？哈哈，如果真的一點辦法都沒有，那我肯定就寫不下去了啊。既然遇到問題了，總得解決不是。這里我先把圖放出來，勾引勾引你們
查詢時間0.055秒，這個結果你們覺得爽不爽？
細心的朋友肯定看到了，我的這個sql中使用了分頁查詢。所以把聯表查詢改造成使用子查詢，再結合分頁查詢，效果立馬就出來了。由此也引出了我要寫的第三部分內容，分頁查詢。
三．分頁查詢
提到這個，很多朋友的第一印象肯定是，頁數越大，查詢速度越慢。大家的感覺是對的，確實如此，我們可以先來測試一下。比如我從第200萬條記錄開始，查詢10條記錄
查詢時間3秒多，如果是配置一般的機器，估計時間會更長。
關於分頁查詢如何優化，百度上一艘一大把，我這里就不廢話了，直接上圖
可見，分頁查詢的優化，也是使用了聯表和子查詢。回想剛才第二部分的聯表查詢，是不是就感覺豁然開朗了呢？（分頁查詢可是很多系統經常使用的功能呢）。
總結
通過一系列的測試，可以看出來，在sql查詢中，並非不是不能使用星號的。只要根據實際情況，合理搭配使用索引，子查詢等優化方法，用星號反而能讓我們少寫不少代碼。而且不用在添加表字段后，再去修改相應的sql查詢語句。當然，如果再搭配sql查詢分析器去做針對性的優化，那就更完美了。
所以，古人誠不欺我，“盡信書不如無書”，說得太對了。必須向前輩們致敬一下。
今天做測試用的數據已上傳到百度雲，朋友們想自己測試娛樂一下的可以去下載。測試數據文件是個sql腳本文件，可以整庫導入。百度雲鏈接如下
鏈接：https://pan.baidu.com/s/1bWNvIyIviC_2swG3rSd3Fg
提取碼：f3of