面試官:爲什麼說Select * 效率低呢?

來源:https://urlify.cn/ZvM3qem

無論在工作還是面試中,關於SQL中不要用SELECT *,都是大家聽爛了的問題,雖說聽爛了,但普遍理解還是在很淺的層面,並沒有多少人去追根究底,探究其原理。

廢話不多說,本文帶你深入瞭解一下"SELECT * "效率低的原因及場景。

本文很乾!請自備茶水,沒時間看記得先收藏  -- 來自一位被技術經理毒打多年的程序員的忠告

一、效率低的原因

先看一下最新《阿里java開發手冊(泰山版)》部分描述:

4 - 1. 【強制】 在表查詢中,一律不要使用 * 作爲查詢的字段列表,需要哪些字段必須明確寫明。說明:

  • 增加查詢分析器解析成本。
  • 增減字段容易與 resultMap 配置不一致。
  • 無用字段增加網絡 消耗,尤其是 text 類型的字段。

開發手冊中比較概括的提到了幾點原因,讓我們深入一些看看:

1. 不需要的列會增加數據傳輸時間和網絡開銷

  1. SELECT * 數據庫需要解析更多的對象、字段、權限、屬性等相關內容,在 SQL 語句複雜,硬解析較多的情況下,會對數據庫造成沉重的負擔。
  2. 增大網絡開銷;* 有時會誤帶上如log、IconMD5之類的無用且大文本字段,數據傳輸size會幾何增漲。如果DB和應用程序不在同一臺機器,這種開銷非常明顯
  3. 即使 mysql 服務器和客戶端是在同一臺機器上,使用的協議還是 tcp,通信也是需要額外的時間。

2. 對於無用的大字段,如 varchar、blob、text,會增加 io 操作

準確來說,長度超過 728 字節的時候,會先把超出的數據序列化到另外一個地方,因此讀取這條記錄會增加一次 io 操作。(MySQL InnoDB)

3. 失去MySQL優化器“覆蓋索引”策略優化的可能性

SELECT * 杜絕了覆蓋索引的可能性,而基於MySQL優化器的“覆蓋索引”策略又是速度極快,效率極高,業界極爲推薦的查詢優化方式。

例如,有一個表爲t(a,b,c,d,e,f),其中,a爲主鍵,b列有索引。

那麼,在磁盤上有兩棵 B+ 樹,即聚集索引和輔助索引(包括單列索引、聯合索引),分別保存(a,b,c,d,e,f)和(a,b),如果查詢條件中where條件可以通過b列的索引過濾掉一部分記錄,查詢就會先走輔助索引,如果用戶只需要a列和b列的數據,直接通過輔助索引就可以知道用戶查詢的數據。

如果用戶使用select *,獲取了不需要的數據,則首先通過輔助索引過濾數據,然後再通過聚集索引獲取所有的列,這就多了一次b+樹查詢,速度必然會慢很多。

由於輔助索引的數據比聚集索引少很多,很多情況下,通過輔助索引進行覆蓋索引(通過索引就能獲取用戶需要的所有列),都不需要讀磁盤,直接從內存取,而聚集索引很可能數據在磁盤(外存)中(取決於buffer pool的大小和命中率),這種情況下,一個是內存讀,一個是磁盤讀,速度差異就很顯著了,幾乎是數量級的差異。

二、索引知識延申

上面提到了輔助索引,在MySQL中輔助索引包括單列索引、聯合索引(多列聯合),單列索引就不再贅述了,這裏提一下聯合索引的作用

聯合索引 (a,b,c)

聯合索引 (a,b,c) 實際建立了 (a)、(a,b)、(a,b,c) 三個索引

我們可以將組合索引想成書的一級目錄、二級目錄、三級目錄,如index(a,b,c),相當於a是一級目錄,b是一級目錄下的二級目錄,c是二級目錄下的三級目錄。要使用某一目錄,必須先使用其上級目錄,一級目錄除外。

如下:

where條件 效果
where a=1 and c=1 只使用了一級目錄,c在三級目錄,沒有使用二級目錄,那麼三級目錄就沒法使用
where a=1 and b=1 只使用了一級目錄、二級目錄。

聯合索引的優勢

1) 減少開銷

建一個聯合索引 (a,b,c) ,實際相當於建了 (a)、(a,b)、(a,b,c) 三個索引。每多一個索引,都會增加寫操作的開銷和磁盤空間的開銷。對於大量數據的表,使用聯合索引會大大的減少開銷!

2)覆蓋索引

對聯合索引 (a,b,c),如果有如下 sql 的,

SELECT a,b,c from table where a='xx' and b = 'xx';

那麼 MySQL 可以直接通過遍歷索引取得數據,而無需回表,這減少了很多的隨機 io 操作。減少 io 操作,特別是隨機 io 其實是 DBA 主要的優化策略。所以,在真正的實際應用中,覆蓋索引是主要的提升性能的優化手段之一。

3)效率高

索引列多,通過聯合索引篩選出的數據越少。比如有 1000W 條數據的表,有如下SQL:

select col1,col2,col3 from table where col1=1 and col2=2 and col3=3;

假設:假設每個條件可以篩選出 10% 的數據。

  • A. 如果只有單列索引,那麼通過該索引能篩選出 1000W10%=100w 條數據,然後再回表從 100w 條數據中找到符合 col2=2 and col3= 3 的數據,然後再排序,再分頁,以此類推(遞歸);
  • B. 如果是(col1,col2,col3)聯合索引,通過三列索引篩選出 1000w10% 10% *10%=1w,效率提升可想而知!

索引是建的越多越好嗎

答案自然是否定的

  • 數據量小的表不需要建立索引,建立會增加額外的索引開銷
  • 不經常引用的列不要建立索引,因爲不常用,即使建立了索引也沒有多大意義
  • 經常頻繁更新的列不要建立索引,因爲肯定會影響插入或更新的效率
  • 數據重複且分佈平均的字段,因此他建立索引就沒有太大的效果(例如性別字段,只有男女,不適合建立索引)
  • 數據變更需要維護索引,意味着索引越多維護成本越高。
  • 更多的索引也需要更多的存儲空間



以上,希望對你有所幫助!



End




乾貨分享



這裏爲大家準備了一份小小的禮物,關注公衆號,輸入如下代碼,即可獲得百度網盤地址,無套路領取!

001:《程序員必讀書籍》
002:《從無到有搭建中小型互聯網公司後臺服務架構與運維架構》
003:《互聯網企業高併發解決方案》
004:《互聯網架構教學視頻》
006:《SpringBoot實現點餐系統》
007:《SpringSecurity實戰視頻》
008:《Hadoop實戰教學視頻》
009:《騰訊2019Techo開發者大會PPT》

010: 微信交流羣


我就知道你“在看”






本文分享自微信公衆號 - JAVA日知錄(javadaily)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章