無(wú)論在工作還是面試中,關(guān)于SQL中不要用“SELECT *”,都是大家聽爛了的問(wèn)題,雖說(shuō)聽爛了,但普遍理解還是在很淺的層面,并沒(méi)有多少人去追根究底,探究其原理。 廢話不多說(shuō),本文帶你深入了解一下"SELECT * "效率低的原因及場(chǎng)景。
目錄一、效率低的原因 1. 不需要的列會(huì)增加數(shù)據(jù)傳輸時(shí)間和網(wǎng)絡(luò)開銷 2. 對(duì)于無(wú)用的大字段,如 varchar、blob、text,會(huì)增加 io 操作 3. 失去MySQL優(yōu)化器“覆蓋索引”策略優(yōu)化的可能性 二、索引知識(shí)延申 ● 聯(lián)合索引 (a,b,c) ● 聯(lián)合索引的優(yōu)勢(shì) 1) 減少開銷 2)覆蓋索引 3)效率高 ● 索引是建的越多越好嗎 三、心得體會(huì) 一、效率低的原因先看一下最新《阿里java開發(fā)手冊(cè)(泰山版)》中 MySQL 部分描述:
說(shuō)明:
開發(fā)手冊(cè)中比較概括的提到了幾點(diǎn)原因,讓我們深入一些看看: 1. 不需要的列會(huì)增加數(shù)據(jù)傳輸時(shí)間和網(wǎng)絡(luò)開銷
2. 對(duì)于無(wú)用的大字段,如 varchar、blob、text,會(huì)增加 io 操作準(zhǔn)確來(lái)說(shuō),長(zhǎng)度超過(guò) 728 字節(jié)的時(shí)候,會(huì)先把超出的數(shù)據(jù)序列化到另外一個(gè)地方,因此讀取這條記錄會(huì)增加一次 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條件可以通過(guò)b列的索引過(guò)濾掉一部分記錄,查詢就會(huì)先走輔助索引,如果用戶只需要a列和b列的數(shù)據(jù),直接通過(guò)輔助索引就可以知道用戶查詢的數(shù)據(jù)。 如果用戶使用 ![]() 由于輔助索引的數(shù)據(jù)比聚集索引少很多,很多情況下,通過(guò)輔助索引進(jìn)行覆蓋索引(通過(guò)索引就能獲取用戶需要的所有列),都不需要讀磁盤,直接從內(nèi)存取,而聚集索引很可能數(shù)據(jù)在磁盤(外存)中(取決于buffer pool的大小和命中率),這種情況下,一個(gè)是內(nèi)存讀,一個(gè)是磁盤讀,速度差異就很顯著了,幾乎是數(shù)量級(jí)的差異。 二、索引知識(shí)延申上面提到了輔助索引,在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è)索引 我們可以將組合索引想成書的一級(jí)目錄、二級(jí)目錄、三級(jí)目錄,如index(a,b,c),相當(dāng)于a是一級(jí)目錄,b是一級(jí)目錄下的二級(jí)目錄,c是二級(jí)目錄下的三級(jí)目錄。要使用某一目錄,必須先使用其上級(jí)目錄,一級(jí)目錄除外。 如下:
聯(lián)合索引的優(yōu)勢(shì)1) 減少開銷建一個(gè)聯(lián)合索引 (a,b,c) ,實(shí)際相當(dāng)于建了 (a)、(a,b)、(a,b,c) 三個(gè)索引。每多一個(gè)索引,都會(huì)增加寫操作的開銷和磁盤空間的開銷。對(duì)于大量數(shù)據(jù)的表,使用聯(lián)合索引會(huì)大大的減少開銷! 2)覆蓋索引對(duì)聯(lián)合索引 (a,b,c),如果有如下 sql 的, 那么 MySQL 可以直接通過(guò)遍歷索引取得數(shù)據(jù),而無(wú)需回表,這減少了很多的隨機(jī) io 操作。減少 io 操作,特別是隨機(jī) io 其實(shí)是 DBA 主要的優(yōu)化策略。所以,在真正的實(shí)際應(yīng)用中,覆蓋索引是主要的提升性能的優(yōu)化手段之一。 3)效率高索引列多,通過(guò)聯(lián)合索引篩選出的數(shù)據(jù)越少。比如有 1000W 條數(shù)據(jù)的表,有如下SQL: 假設(shè):假設(shè)每個(gè)條件可以篩選出 10% 的數(shù)據(jù)。
索引是建的越多越好嗎答案自然是否定的
三、心得體會(huì)相信能看到這里這老鐵要么是對(duì)MySQL有著一腔熱血的,要么就是喜歡滾鼠標(biāo)的。來(lái)了就是緣分,如果從本文學(xué)到了東西,請(qǐng)不要吝嗇手中的贊哦,拒絕白嫖~ 有朋友問(wèn)我,你對(duì)SQL規(guī)范那么上心,平時(shí)你寫代碼不會(huì)用SELECT * 吧? 咋可能啊,天天用。。代碼里也在用(一臉羞愧),其實(shí)我們的項(xiàng)目普遍很小,數(shù)據(jù)量也上不去,性能上還沒(méi)有遇到瓶頸,所以比較放縱。 寫本篇文章主要是這個(gè)知識(shí)點(diǎn)網(wǎng)上總結(jié)的很少很散,也不規(guī)范,算是給自己也是給大家總結(jié)一份比較詳細(xì)的,值得記一下的。以后給面試官說(shuō)完讓他沒(méi)法找你茬。 順便吹波牛B,謝謝各位。
|
|
|
來(lái)自: 正合叔 > 《數(shù)據(jù)庫(kù)》