導(dǎo)致select*效率低下的原因是什么

本篇內(nèi)容主要講解“導(dǎo)致select * 效率低下的原因是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“導(dǎo)致select * 效率低下的原因是什么”吧!

網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)！專注于網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、小程序開發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了陽新免費(fèi)建站歡迎大家使用！

一、效率低的原因  

說明：

  • 增加查詢分析器解析成本。

  • 增減字段容易與 resultMap 配置不一致。

  • 無用字段增加網(wǎng)絡(luò) 消耗，尤其是 text 類型的字段。

開發(fā)手冊中比較概括的提到了幾點(diǎn)原因，讓我們深入一些看看：

1. 不需要的列會增加數(shù)據(jù)傳輸時(shí)間和網(wǎng)絡(luò)開銷

  1. 用“SELECT * ”數(shù)據(jù)庫需要解析更多的對象、字段、權(quán)限、屬性等相關(guān)內(nèi)容，在 SQL 語句復(fù)雜，硬解析較多的情況下，會對數(shù)據(jù)庫造成沉重的負(fù)擔(dān)。

  2. 增大網(wǎng)絡(luò)開銷；* 有時(shí)會誤帶上如log、IconMD5之類的無用且大文本字段，數(shù)據(jù)傳輸size會幾何增漲。如果DB和應(yīng)用程序不在同一臺機(jī)器，這種開銷非常明顯

  3. 即使 MySQL 服務(wù)器和客戶端是在同一臺機(jī)器上，使用的協(xié)議還是 tcp，通信也是需要額外的時(shí)間。

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

準(zhǔn)確來說，長度超過 728 字節(jié)的時(shí)候，會先把超出的數(shù)據(jù)序列化到另外一個(gè)地方，因此讀取這條記錄會增加一次 io 操作。（MySQL InnoDB）

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

SELECT * 杜絕了覆蓋索引的可能性，而基于MySQL優(yōu)化器的“覆蓋索引”策略又是速度極快，效率極高，業(yè)界極為推薦的查詢優(yōu)化方式。
例如，有一個(gè)表為t(a,b,c,d,e,f)，其中，a為主鍵，b列有索引。
那么，在磁盤上有兩棵 B+ 樹，即聚集索引和輔助索引（包括單列索引、聯(lián)合索引），分別保存(a,b,c,d,e,f)和(a,b)，如果查詢條件中where條件可以通過b列的索引過濾掉一部分記錄，查詢就會先走輔助索引，如果用戶只需要a列和b列的數(shù)據(jù)，直接通過輔助索引就可以知道用戶查詢的數(shù)據(jù)。
如果用戶使用select *，獲取了不需要的數(shù)據(jù)，則首先通過輔助索引過濾數(shù)據(jù)，然后再通過聚集索引獲取所有的列，這就多了一次b+樹查詢，速度必然會慢很多。
導(dǎo)致select * 效率低下的原因是什么
由于輔助索引的數(shù)據(jù)比聚集索引少很多，很多情況下，通過輔助索引進(jìn)行覆蓋索引（通過索引就能獲取用戶需要的所有列），都不需要讀磁盤，直接從內(nèi)存取，  而聚集索引很可能數(shù)據(jù)在磁盤（外存）中（取決于buffer pool的大小和命中率），這種情況下，一個(gè)是內(nèi)存讀，一個(gè)是磁盤讀，速度差異就很顯著了，幾乎是數(shù)量級的差異。

導(dǎo)致select * 效率低下的原因是什么

二、索引知識延申

上面提到了輔助索引，在MySQL中輔助索引包括單列索引、聯(lián)合索引（多列聯(lián)合），單列索引就不再贅述了，這里提一下聯(lián)合索引的作用

聯(lián)合索引 (a,b,c)

聯(lián)合索引 (a,b,c) 實(shí)際建立了 (a)、(a,b)、(a,b,c) 三個(gè)索引
我們可以將組合索引想成書的一級目錄、二級目錄、三級目錄，如index(a,b,c)，相當(dāng)于a是一級目錄，b是一級目錄下的二級目錄，c是二級目錄下的三級目錄。要使用某一目錄，必須先使用其上級目錄，一級目錄除外。
如下：
導(dǎo)致select * 效率低下的原因是什么

 聯(lián)合索引的優(yōu)勢

1） 減少開銷

建一個(gè)聯(lián)合索引 (a,b,c) ，實(shí)際相當(dāng)于建了 (a)、(a,b)、(a,b,c) 三個(gè)索引。每多一個(gè)索引，都會增加寫操作的開銷和磁盤空間的開銷。對于大量數(shù)據(jù)的表，使用聯(lián)合索引會大大的減少開銷！

2）覆蓋索引

對聯(lián)合索引 (a,b,c)，如果有如下 sql 的，
   
   
   SELECT a,b,c from table where a='xx' and b = 'xx';
那么 MySQL 可以直接通過遍歷索引取得數(shù)據(jù)，而無需回表，這減少了很多的隨機(jī) io 操作。減少 io 操作，特別是隨機(jī) io 其實(shí)是 DBA 主要的優(yōu)化策略。所以，在真正的實(shí)際應(yīng)用中，覆蓋索引是主要的提升性能的優(yōu)化手段之一。

3）效率高

索引列多，通過聯(lián)合索引篩選出的數(shù)據(jù)越少。比如有 1000W 條數(shù)據(jù)的表，有如下SQL:
   
   
   select col1,col2,col3 from table where col1=1 and col2=2 and col3=3;
假設(shè)：  假設(shè)每個(gè)條件可以篩選出 10% 的數(shù)據(jù)。  

  • A. 如果只有單列索引，那么通過該索引能篩選出 1000W10%=100w 條數(shù)據(jù)，然后再回表從 100w 條數(shù)據(jù)中找到符合 col2=2 and col3= 3 的數(shù)據(jù)，然后再排序，再分頁，以此類推（遞歸）；

  • B. 如果是（col1,col2,col3）聯(lián)合索引，通過三列索引篩選出 1000w10% 10% *10%=1w，效率提升可想而知！

索引是建的越多越好嗎

       答案自然是否定的

  • 數(shù)據(jù)量小的表不需要建立索引，建立會增加額外的索引開銷

  • 不經(jīng)常引用的列不要建立索引，因?yàn)椴怀Ｓ茫词菇⒘怂饕矝]有多大意義

  • 經(jīng)常頻繁更新的列不要建立索引，因?yàn)榭隙〞绊懖迦牖蚋碌男?/p>

  • 數(shù)據(jù)重復(fù)且分布平均的字段，因此他建立索引就沒有太大的效果（例如性別字段，只有男女，不適合建立索引）

  • 數(shù)據(jù)變更需要維護(hù)索引，意味著索引越多維護(hù)成本越高。

  • 更多的索引也需要更多的存儲空間

到此，相信大家對“導(dǎo)致select * 效率低下的原因是什么”有了更深的了解，不妨來實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

標(biāo)題名稱：導(dǎo)致select*效率低下的原因是什么
鏈接分享：http://muchs.cn/article0/jeheio.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)公司、ChatGPT、、App開發(fā)、網(wǎng)站營銷

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)

網(wǎng)站優(yōu)化排名