歡迎來到裝配圖網(wǎng)! | 幫助中心 裝配圖網(wǎng)zhuangpeitu.com!
裝配圖網(wǎng)
ImageVerifierCode 換一換
首頁 裝配圖網(wǎng) > 資源分類 > DOCX文檔下載  

干貨:高效率sql規(guī)范化書寫標(biāo)準(zhǔn)sql語句編寫格式規(guī)范

  • 資源ID:210939921       資源大?。?span id="cnbdcnk" class="font-tahoma">24.18KB        全文頁數(shù):8頁
  • 資源格式: DOCX        下載積分:9.98積分
快捷下載 游客一鍵下載
會員登錄下載
微信登錄下載
三方登錄下載: 微信開放平臺登錄 支付寶登錄   QQ登錄   微博登錄  
二維碼
微信掃一掃登錄
下載資源需要9.98積分
郵箱/手機:
溫馨提示:
用戶名和密碼都是您填寫的郵箱或者手機號,方便查詢和重復(fù)下載(系統(tǒng)自動生成)
支付方式: 支付寶    微信支付   
驗證碼:   換一換

 
賬號:
密碼:
驗證碼:   換一換
  忘記密碼?
    
友情提示
2、PDF文件下載后,可能會被瀏覽器默認(rèn)打開,此種情況可以點擊瀏覽器菜單,保存網(wǎng)頁到桌面,就可以正常下載了。
3、本站不支持迅雷下載,請使用電腦自帶的IE瀏覽器,或者360瀏覽器、谷歌瀏覽器下載即可。
4、本站資源下載后的文檔和圖紙-無水印,預(yù)覽文檔經(jīng)過壓縮,下載后原文更清晰。
5、試題試卷類文檔,如果標(biāo)題沒有明確說明有答案則都視為沒有答案,請知曉。

干貨:高效率sql規(guī)范化書寫標(biāo)準(zhǔn)sql語句編寫格式規(guī)范

干貨!SQL性能優(yōu)化,書寫高質(zhì)量SQL語句寫SQL語句的時候我們往往關(guān)注的是SQL的執(zhí)行結(jié)果,但是是否真的關(guān)注了SQL的執(zhí)行效率,是否注意了SQL的寫法規(guī)范?以下的干貨分享是在實際開發(fā)過程中總結(jié)的,希望對大家有所幫助!limit分頁優(yōu)化當(dāng)偏移量特別大時,limit效率會非常低。SELECT id FROM A LIMIT 1000,10 很快SELECT id FROM A LIMIT 90000,10 很慢方案一:select id from A order by id limit 90000,10;如果我們結(jié)合order by使用。很快,0.04秒就OK。 因為使用了id主鍵做索引!當(dāng)然,是否能夠使用索引還需要根據(jù)業(yè)務(wù)邏輯來定,這里只是為了提醒大家,在分頁的時候還需謹(jǐn)慎使用!方案二select id from A order by id between 90000 and 90010;利用limit 1 、top 1 取得一行有些業(yè)務(wù)邏輯進(jìn)行查詢操作時(特別是在根據(jù)某一字段DESC,取最大一筆).可以使用limit 1 或者 top 1 來終止數(shù)據(jù)庫索引繼續(xù)掃描整個表或索引。反例SELECT id FROM A LIKE 'abc%' 正例SELECT id FROM A LIKE 'abc%' limit 1任何情況都不要用 select * from table ,用具體的字段列表替換"*",不要返回用不到的字段,避免全盤掃描!批量插入優(yōu)化反例INSERT into person(name,age) values('A',24)INSERT into person(name,age) values('B',24)INSERT into person(name,age) values('C',24)正例INSERT into person(name,age) values('A',24),('B',24),('C',24sql語句的優(yōu)化主要在于對索引的正確使用,而我們在開發(fā)中經(jīng)常犯的錯誤便是對表進(jìn)行全盤掃描,一來影響性能,而來耗費時間!like語句的優(yōu)化反例SELECT id FROM A WHERE name like '%abc%'由于abc前面用了“%”,因此該查詢必然走全表查詢,除非必要(模糊查詢需要包含abc),否則不要在關(guān)鍵詞前加%正例SELECT id FROM A WHERE name like 'abc%'where子句使用 in 或 not in 的優(yōu)化sql語句中 in 和 not in 的使用請慎用!使用in 或者 not in 會丟棄索引,從而進(jìn)行全盤掃描!方案一:between 替換 in反例SELECT id FROM A WHERE num in (1,2,3) 正例SELECT id FROM A WHERE num between 1 and 3方案二:exist 替換 in注:關(guān)于exist和in的用法,片尾有彩蛋反例SELECT id FROM A WHERE num in (select num from B)正例SELECT num FROM A WHERE num exists (select 1 from B where B.num = A.num)方案三:left join 替換 in反例SELECT id FROM A WHERE num in (select num from B) 正例SELECT id FROM A LEFT JOIN B ON A.num = B.num復(fù)制代碼where子句使用or的優(yōu)化通常使用 union all 或 union 的方式替換“or”會得到更好的效果。where子句中使用了or關(guān)鍵字,索引將被放棄使用。反例SELECT id FROM A WHERE num = 10 or num = 20正例SELECT id FROM A WHERE num = 10 union all SELECT id FROM A WHERE num=20where子句中使用 IS NULL 或 IS NOT NULL 的優(yōu)化反例SELECT id FROM A WHERE num IS NULL在where子句中使用 IS NULL 或 IS NOT NULL 判斷,索引將被放棄使用,會進(jìn)行全表查詢。正例優(yōu)化成num上設(shè)置默認(rèn)值0,確保表中num沒有null值, IS NULL 的用法在實際業(yè)務(wù)場景下SQL使用率極高,我們應(yīng)注意避免全表掃描SELECT id FROM A WHERE num=0where子句中對字段進(jìn)行表達(dá)式操作的優(yōu)化不要在where子句中的“=”左邊進(jìn)行函數(shù)、算數(shù)運算或其他表達(dá)式運算,否則系統(tǒng)將可能無法正確使用索引。· 1SELECT id FROM A WHERE datediff(day,createdate,'2019-11-30')=0 優(yōu)化為SELECT id FROM A WHERE createdate>='2019-11-30' and createdate<'2019-12-1'· 2SELECT id FROM A WHERE year(addate) <2020優(yōu)化為SELECT id FROM A where addate<'2020-01-01'排序的索引問題mysql查詢只是用一個索引,因此如果where子句中已經(jīng)使用了索引的話,那么order by中的列是不會使用索引。因此數(shù)據(jù)庫默認(rèn)排序可以符合要求情況下不要使用排序操作;盡量不要包含多個列的排序,如果需要最好給這些列創(chuàng)建復(fù)合索引。盡量用 union all 替換 unionunion和union all的差異主要是前者需要將兩個(或者多個)結(jié)果集合并后再進(jìn)行唯一性過濾操作,這就會涉及到排序,增加大量的cpu運算,加大資源消耗及延遲。所以當(dāng)我們可以確認(rèn)不可能出現(xiàn)重復(fù)結(jié)果集或者不在乎重復(fù)結(jié)果集的時候,盡量使用union all而不是unionInner join 和 left join、right join、子查詢· 第一:inner join內(nèi)連接也叫等值連接是,left/rightjoin是外連接。SELECT A.id,A.name,B.id,B.name FROM A LEFT JOIN B ON A.id =B.id;SELECT A.id,A.name,B.id,B.name FROM A RIGHT JOIN ON B A.id= B.id;SELECT A.id,A.name,B.id,B.name FROM A INNER JOIN ON A.id =B.id;經(jīng)過來之多方面的證實 inner join性能比較快,因為inner join是等值連接,或許返回的行數(shù)比較少。但是我們要記得有些語句隱形的用到了等值連接,如:SELECT A.id,A.name,B.id,B.name FROM A,B WHERE A.id = B.id;推薦:能用inner join連接盡量使用inner join連接· 第二:子查詢的性能又比外連接性能慢,盡量用外連接來替換子查詢。反例mysql是先對外表A執(zhí)行全表查詢,然后根據(jù)uuid逐次執(zhí)行子查詢,如果外層表是一個很大的表,我們可以想象查詢性能會表現(xiàn)比這個更加糟糕。Select* from A where exists (select * from B where id>=3000 and A.uuid=B.uuid);執(zhí)行時間:2s左右正例Select* from A inner join B ON A.uuid=B.uuid where b.uuid>=3000; 這個語句執(zhí)行測試不到一秒;執(zhí)行時間:1s不到· 第三:使用JOIN時候,應(yīng)該用小的結(jié)果驅(qū)動大的結(jié)果left join 左邊表結(jié)果盡量小,如果有條件應(yīng)該放到左邊先處理,right join同理反向。如:反例Select * from A left join B A.id=B.ref_id where A.id>10正例select * from (select * from A wehre id >10) T1 left join B on T1.id=B.ref_id;exist 代替 in反例SELECT * from A WHERE id in ( SELECT id from B )正例SELECT * from A WHERE id EXISTS ( SELECT 1 from A.id= B.id )分析:in 是在內(nèi)存中遍歷比較exist 需要查詢數(shù)據(jù)庫,所以當(dāng)B的數(shù)據(jù)量比較大時,exists效率優(yōu)于in*in()只執(zhí)行一次,把B表中的所有id字段緩存起來,之后檢查A表的id是否與B表中的id相等,如果id相等則將A表的記錄加入到結(jié)果集中,直到遍歷完A表的所有記錄。In 操作的流程原理如同一下代碼 List resultSet=; Array A=(select * from A); Array B=(select id from B); for(int i=0;i<A.length;i+) for(int j=0;j<B.length;j+) if(Ai.id=Bj.id) resultSet.add(Ai); break; return resultSet;可以看出,當(dāng)B表數(shù)據(jù)較大時不適合使用in(),因為會把B表數(shù)據(jù)全部遍歷一次如:A表有10000條記錄,B表有1000000條記錄,那么最多有可能遍歷10000*1000000次,效率很差。再如:A表有10000條記錄,B表有100條記錄,那么最多有可能遍歷10000*100次,遍歷次數(shù)大大減少,效率大大提升。結(jié)論:in()適合B表比A表數(shù)據(jù)小的情況exist()會執(zhí)行A.length()次,執(zhí)行過程代碼如下List resultSet=;Array A=(select * from A);for(int i=0;i<A.length;i+) if(exists(Ai.id) /執(zhí)行select 1 from B where B.id=A.id是否有記錄返回 resultSet.add(Ai); return resultSet;當(dāng)B表比A表數(shù)據(jù)大時適合使用exists(),因為它沒有那么多遍歷操作,只需要再執(zhí)行一次查詢就行。如:A表有10000條記錄,B表有1000000條記錄,那么exists()會執(zhí)行10000次去判斷A表中的id是否與B表中的id相等。如:A表有10000條記錄,B表有100000000條記錄,那么exists()還是執(zhí)行10000次,因為它只執(zhí)行A.length次,可見B表數(shù)據(jù)越多,越適合exists()發(fā)揮效果。再如:A表有10000條記錄,B表有100條記錄,那么exists()還是執(zhí)行10000次,還不如使用in()遍歷10000*100次,因為in()是在內(nèi)存里遍歷比較,而exists()需要查詢數(shù)據(jù)庫,我們都知道查詢數(shù)據(jù)庫所消耗的性能更高,而內(nèi)存比較很快。 結(jié)論:exists()適合B表比A表數(shù)據(jù)大的情況

注意事項

本文(干貨:高效率sql規(guī)范化書寫標(biāo)準(zhǔn)sql語句編寫格式規(guī)范)為本站會員(ta****fu)主動上傳,裝配圖網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對上載內(nèi)容本身不做任何修改或編輯。 若此文所含內(nèi)容侵犯了您的版權(quán)或隱私,請立即通知裝配圖網(wǎng)(點擊聯(lián)系客服),我們立即給予刪除!

溫馨提示:如果因為網(wǎng)速或其他原因下載失敗請重新下載,重復(fù)下載不扣分。




關(guān)于我們 - 網(wǎng)站聲明 - 網(wǎng)站地圖 - 資源地圖 - 友情鏈接 - 網(wǎng)站客服 - 聯(lián)系我們

copyright@ 2023-2025  zhuangpeitu.com 裝配圖網(wǎng)版權(quán)所有   聯(lián)系電話:18123376007

備案號:ICP2024067431-1 川公網(wǎng)安備51140202000466號


本站為文檔C2C交易模式,即用戶上傳的文檔直接被用戶下載,本站只是中間服務(wù)平臺,本站所有文檔下載所得的收益歸上傳人(含作者)所有。裝配圖網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對上載內(nèi)容本身不做任何修改或編輯。若文檔所含內(nèi)容侵犯了您的版權(quán)或隱私,請立即通知裝配圖網(wǎng),我們立即給予刪除!