您好,登錄后才能下訂單哦!
這篇“mysql的SELECT效率低的原因有哪些”文章的知識點大部分人都不太理解,所以小編給大家總結了以下內(nèi)容,內(nèi)容詳細,步驟清晰,具有一定的借鑒價值,希望大家閱讀完這篇文章能有所收獲,下面我們一起來看看這篇“mysql的SELECT效率低的原因有哪些”文章吧。
先看一下最新《阿里java開發(fā)手冊(泰山版)》中 MySQL 部分描述:
4 - 1. 【強制】在表查詢中,一律不要使用 * 作為查詢的字段列表,需要哪些字段必須明確寫明。
說明:
增加查詢分析器解析成本。
增減字段容易與 resultMap 配置不一致。
無用字段增加網(wǎng)絡 消耗,尤其是 text 類型的字段。
開發(fā)手冊中比較概括的提到了幾點原因,讓我們深入一些看看:
用“SELECT * ”數(shù)據(jù)庫需要解析更多的對象、字段、權限、屬性等相關內(nèi)容,在 SQL 語句復雜,硬解析較多的情況下,會對數(shù)據(jù)庫造成沉重的負擔。
增大網(wǎng)絡開銷;* 有時會誤帶上如log、IconMD5之類的無用且大文本字段,數(shù)據(jù)傳輸size會幾何增漲。如果DB和應用程序不在同一臺機器,這種開銷非常明顯
即使 mysql 服務器和客戶端是在同一臺機器上,使用的協(xié)議還是 tcp,通信也是需要額外的時間。
準確來說,長度超過 728 字節(jié)的時候,會先把超出的數(shù)據(jù)序列化到另外一個地方,因此讀取這條記錄會增加一次 io 操作。(MySQL InnoDB)
SELECT * 杜絕了覆蓋索引的可能性,而基于MySQL優(yōu)化器的“覆蓋索引”策略又是速度極快,效率極高,業(yè)界極為推薦的查詢優(yōu)化方式。
例如,有一個表為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+樹查詢,速度必然會慢很多。
由于輔助索引的數(shù)據(jù)比聚集索引少很多,很多情況下,通過輔助索引進行覆蓋索引(通過索引就能獲取用戶需要的所有列),都不需要讀磁盤,直接從內(nèi)存取,而聚集索引很可能數(shù)據(jù)在磁盤(外存)中(取決于buffer pool的大小和命中率),這種情況下,一個是內(nèi)存讀,一個是磁盤讀,速度差異就很顯著了,幾乎是數(shù)量級的差異。
上面提到了輔助索引,在MySQL中輔助索引包括單列索引、聯(lián)合索引(多列聯(lián)合),單列索引就不再贅述了,這里提一下聯(lián)合索引的作用
聯(lián)合索引 (a,b,c) 實際建立了 (a)、(a,b)、(a,b,c) 三個索引
我們可以將組合索引想成書的一級目錄、二級目錄、三級目錄,如index(a,b,c),相當于a是一級目錄,b是一級目錄下的二級目錄,c是二級目錄下的三級目錄。要使用某一目錄,必須先使用其上級目錄,一級目錄除外。
如下:
建一個聯(lián)合索引 (a,b,c) ,實際相當于建了 (a)、(a,b)、(a,b,c) 三個索引。每多一個索引,都會增加寫操作的開銷和磁盤空間的開銷。對于大量數(shù)據(jù)的表,使用聯(lián)合索引會大大的減少開銷!
對聯(lián)合索引 (a,b,c),如果有如下 sql 的,
SELECT a,b,c from table where a='xx' and b = 'xx';
那么 MySQL 可以直接通過遍歷索引取得數(shù)據(jù),而無需回表,這減少了很多的隨機 io 操作。減少 io 操作,特別是隨機 io 其實是 DBA 主要的優(yōu)化策略。所以,在真正的實際應用中,覆蓋索引是主要的提升性能的優(yōu)化手段之一。
索引列多,通過聯(lián)合索引篩選出的數(shù)據(jù)越少。比如有 1000W 條數(shù)據(jù)的表,有如下SQL:
select col1,col2,col3 from table where col1=1 and col2=2 and col3=3;
假設:假設每個條件可以篩選出 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)常引用的列不要建立索引,因為不常用,即使建立了索引也沒有多大意義
經(jīng)常頻繁更新的列不要建立索引,因為肯定會影響插入或更新的效率
數(shù)據(jù)重復且分布平均的字段,因此他建立索引就沒有太大的效果(例如性別字段,只有男女,不適合建立索引)
數(shù)據(jù)變更需要維護索引,意味著索引越多維護成本越高。
更多的索引也需要更多的存儲空間
以上就是關于“mysql的SELECT效率低的原因有哪些”這篇文章的內(nèi)容,相信大家都有了一定的了解,希望小編分享的內(nèi)容對大家有幫助,若想了解更多相關的知識內(nèi)容,請關注億速云行業(yè)資訊頻道。
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權內(nèi)容。