【原創】Mysql中select的正確姿式

引言

你們在開發中，還有不少童鞋在寫查詢語句的時候，習慣寫下面這種不規範sql

select * from table

而不寫成下面的這種規範方式

select col1,col2,...,coln from table

我也知道，這些童鞋是圖方便，畢竟再敲一堆的列名，嫌麻煩!
大家上班能夠問問本身的同事

你：「xx，知道select *和select全部字段的區別麼？
同事:"額。。額。。額。。"
留下的只有尷尬的笑容！

我也知道，不少人至今都沒有搞懂select *和selct 全部字段的區別
所以，我開一文來講明一下。另外，我選的是本身最熟悉的mysql數據庫，此文的結論在oralce,sqlserver上是否成立，博主沒作過測試。

正文

(select全部字段)性能高?

網絡上流傳着一種說法說是

「*」 表示通配全部字段，在SQL的機制裏，須要先識別統計全部字段再進行下一步。
明確指定字段的話，會減小上述的操做，因此效率有所提高。

然而，實際上呢？效率是相差不大的！。
取博客
http://flysnowxf.iteye.com/blog/1125032
的測試結果
mysql 5.1.37
表記錄數41,547,002，即4000w行
使用遠程客戶端取1000條數據，統計時間：

SELECT * FROM `dmsp`.`dmsp_dimension_content` LIMIT 0, 1000;

時間2.218s，網絡消耗0.547s

SELECT `id`, `appid`, `aop`, `t`, `uid`, `sid`, `pid`, `pname`, `bid`, `bname`, `ptype`, `sm`, `sv`, `bt`, `national`, `area`, `ov` FROM `dmsp`.`dmsp_dimension_content` LIMIT 0, 1000;

取出全部字段，時間2.250s，網絡消耗0.578s
能夠看出，這兩者的時間差幾乎能夠忽略，另外還有一本書上的內容也能夠佐證個人話。
《SQL CookBook》第一章 檢索記錄中1.1小節（原書第十五頁內容以下）：

此書也說明了，兩種方式在性能上幾乎是沒有差距的。
那爲何仍是不推薦select * ?

網絡IO問題

不少文章裏說什麼，會帶來額外的內存、磁盤、cpu的開銷。對此，我有本身的觀點。我以爲這不是主要緣由。主要緣由是帶來了額外的網絡開銷。
在一個系統中，內存、磁盤、cpu的開銷，不過是微妙級。形成系統的延遲的重頭戲是網絡開銷。網絡開銷可能帶來秒級的延遲。固然，若是你的應用程序和數據庫是在同一臺機器上的，那當我沒說這句話！
select *會查詢出不須要的、額外的數據，那麼這些額外的數據在網絡上進行傳輸，一定會形成性能延遲。假設你的table中，有一個列的類型爲binary。此時，你的select *操做，就會十分緩慢，而且會形成額外的網絡開銷。

索引問題

仔細看下面的兩句sql

select col1 from table;
select * from table;

若是col1字段包含索引信息，那麼此時，這兩句的sql執行時間可能會有幾十上百倍的差別。
在col1字段有索引的狀況下，mysql是能夠不用讀data，直接使用index裏面的值就返回結果的。可是一旦用了select *，就會有其餘列須要讀取，這時在讀完index之後還須要去讀data纔會返回結果。這樣就形成了額外的性能開銷。

ps：我不想在這裏扯什麼覆蓋索引，輔助索引的概念。其實要講的很專業，扯一堆高大上的名詞，我也能夠。只是這樣徒增讀者的理解難度，儘可能用通俗的方式來說。

擴展性問題

有的人會以爲

使用select * ，這樣在增長列的時候，不用改sql，方便！

然而實際上，你的sql是不用改了，可是對你的程序代碼是有很大的影響的！
身爲一名21世紀的優良程序員，咱們是不能獲取本身須要的東西的！你由於一時高興，執行了select *，若是增長或刪除列，會對你的代碼有着極大的影響。
反過來，若是你select 指定列，只獲取本身須要的幾列，表結構的修改，對你代碼的影響就會小不少。相比之下，風險就沒有那麼大了！
另外就是，對於其餘人接手你項目的人來講，看到select 指定列的方式，可讀性更強，對於他們來講更好上手！