為什麼公司不準使用SQL語句查詢的「*」？

01-13

可能我描述的不清楚，問題說明：不是樓下各位大大所說的為了其他什麼解耦合神馬的，因為這裡的查詢是針對Bean的封裝查詢，單表，所以肯定是有幾個欄位查幾個欄位，經理提出這一點純粹是為了提高效率，如果以後表有新增欄位，這邊不用*肯定還是要修改代碼的，但在我看來，我們的網站沒有淘寶這些NB的電子商務網站的訪問量，如果一個表有三五十個欄位，為提高資料庫效率而浪費後續這麼多人工，真的值得嗎，我的意思是這個，親們？

我要是你們經理你就慘了，知道為什麼嗎？

1.技術不過關

2.不服從直接領導

什麼叫一點效率？！你知道就為了追求你所謂的那一點點效率dba們天天都在幹什麼嗎？就是給各種不靠譜的研發擦屁股！

的確你一個語句看不出來什麼，的確測試環境的數據沒多少查詢寫多爛都沒事

你想過上到生產就這提高的你所謂一點點效率問題有多大影響嗎？？

還有像什麼數據表結構更改導致bug這種基礎問題我都懶得具體說了

我建議你還是多學習，你是web開發沒錯，但多掌握點db知識對你以後有好處

最後我提點建議。

你問這個問題的心態值得商榷，如果你是一個合格的研發，問題應該是這樣的：為什麼查詢語句不可以用*

可是現在你問的方式只是在發牢騷，不問為什麼，不主動學習，這對於搞IT的人來說是很危險的信號

PS:我補充一下，說性能不是主要原因的，你們是真的沒有前端因為爛查詢導致頁面乃至整站掛掉，被半夜叫起來加班改查詢的情況嗎？？

潛在BUG是問題，性能也是問題，同等重要，沒有主次

用*當然不好，哪天db的schema做了點小變動，譬如說插入了一個column，結果你客戶端沒改，就呵呵了。這不是效率問題，是解耦的問題。你們的產品狗的做法是對的，只是他不知道為什麼要那麼做胡說了一通而已。

SQL查詢里看到 * ,就有一種強烈的違和感,就像看到表裡沒有主鍵一樣.

這不是性能問題，這是讓你代碼更嚴謹，不會應為ddl導致程序可能的出錯。舉個簡單例子。

select id，b.* from a，b …

這個sql看起來沒問題，某天b表加了個 id 欄位，那麼你這個sql就會報錯

性能是次要原因，解耦是主要原因。

不過他方法不對，如果是我，會直接讓這種查詢報錯，然後你就沒這麼多疑問了。

你是沒看過任何公司的編碼規範吧？

在一般的編碼規範里，一般連一個括弧放到上一行行尾還是另起一行、縮進是用tab還是用幾個空格、一行的if也必須帶大括弧，這些個無關痛癢的你都必須得遵守規定。

現在老大說要你select時不要用*這種都已經關乎性能的東西的時候，你都不願意遵守規定？

先說，服從領導。

再想想原因。

我認為：

恐怕不僅僅為了效率，是為了保護軟體升級，同時升級資料庫結構的欄位的同時，不要把後期的敏感欄位內的數據取出來。畢竟公司人來人往，代碼量太大，這個約束，絕對可以少點紕漏。

因為你們公司招不起牛人的人, 只好試著調教二貨

少年每次寫sql 前面加個explain 比較下你就知道為什麼要有規範了

最開始我用*，十年前我開始強迫寫列名，後來我又用回*。

性能也好，解藕也好，用*也都是可以很好解決的。這些方面解決得不好的話，就乖乖寫列名吧。

盲目服從是不對的，懂得問為什麼，勤于思考，不斷理性質疑習慣是好態度。

不讓用select *的原因，諸位大神已經回答的比較完善了。被 select *坑過N回的，流淚佔座。

每個項目組都有自己的規範。項目組成員亦然，大家隨心所欲項目管理起來就難了。

這個屬於基本常識，請回去補習

用*小表可以，數據量大會進行全盤掃描，IO佔用很大，如果在高峰期，一個*能把庫跑死！

還有一點是數據安全問題。比如常見的payroll系統會在employee table裡面放個人資料和一些稅務信息。如果你需要和另一個系統整合的時候，提供一個介面提供非敏感的個人信息，你會希望*不會出現在任何的查詢中。

國內情況不知怎樣，有些國家，這種事故的責任人可能是要坐牢的

工具基本都自帶生成簡單SQL的功能啊，點一下就好了。

Bean什麼的也可以自動生成的。

當然寫一個符合公司代碼規範，針對簡單操作（比如QIUD）常用操作的SQL和Bean的小輪子也花不了幾個小時。

為什麼要人工來寫這些重複的簡單代碼呢，還是「這麼多人工」？我以為這才是浪費時間。

還有堅決不認同「單表，所以肯定是有幾個欄位查幾個欄位」。

家長為什麼不讓孩子玩火，因為他沒有控制能力。

准使用SQL語句查詢的產品已經相當友善了！

產品狗居然允許你們用sql？

竟然木有sql prompt ………