自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

不要這樣寫SQL 改掉這些壞習(xí)慣

數(shù)據(jù)庫
SQL是作為一個程序員接觸得非常多的一種語言,但是,很多時候,我們會發(fā)現(xiàn),有些SQL的執(zhí)行效率異常的差,造成了數(shù)據(jù)庫的負(fù)擔(dān)。

 SQL是作為一個程序員接觸得非常多的一種語言,但是,很多時候,我們會發(fā)現(xiàn),有些SQL的執(zhí)行效率異常的差,造成了數(shù)據(jù)庫的負(fù)擔(dān)。我們通過分析這些有問題的SQL,就可以發(fā)現(xiàn)很多我們平時在寫SQL的時候忽略的問題。

今天,我們就來講一下這些需要改掉的壞習(xí)慣。

盡量少用負(fù)向條件查詢

假設(shè)我們有一個Order表,表中有一個字段是Status,這個字段有4個值,分別是0=待支付、1=待發(fā)貨、2=待收貨、3=已完成。

這時,我們要查詢所有已經(jīng)支付的訂單,很多人就會寫這樣的SQL: 

  1. select * from Order where Status != 0 

這就是一個不好的習(xí)慣了。負(fù)向條件查詢(例如:!=、not in、not exists)都是不能使用索引的,當(dāng)Order表中的數(shù)據(jù)到達(dá)一定量級時,這個查詢的效率會急劇的下降。

 

[[246442]]

 

所以,正確的寫法應(yīng)該是: 

  1. select * from Order where Status in (1,2,3) 

盡量少用前導(dǎo)模糊查詢

假設(shè)我們現(xiàn)在要根據(jù)用戶的訂單號(OrderNo)查詢用戶的訂單,如果是直接通過SQL查詢的話,盡量不要使用前導(dǎo)模糊查詢,也就是: 

  1. select * from Order where OrderNo like '%param' 

或者 

  1. select * from Order where OrderNo like '%param%' 

因為,前導(dǎo)模糊查詢是無法***索引的,所以,會整個數(shù)據(jù)庫去檢索,效率相當(dāng)?shù)牟睿乔皩?dǎo)模糊查詢則是可以使用索引的。 

[[246443]] 

因此,我們盡量不要把通配符放在前面,改成下面這樣: 

  1. select * from Order where OrderNo like 'param%'  
[[246444]] 

盡量不要在條件字段上進(jìn)行運(yùn)算

假設(shè),現(xiàn)在有一個需求,是要查詢2018年全年的訂單數(shù)據(jù),我們就需要通過創(chuàng)建時間(CreateTime)來進(jìn)行檢索,但是,有些程序員就喜歡這樣寫SQL: 

  1. select * from Order where Year(CreateTime)=2018 

然后,每次執(zhí)行時就會發(fā)現(xiàn),查詢的速度異常的慢,導(dǎo)致了大量的請求掛起甚至超時。這是因為,我們即使在CreateTime上建立了索引,但是,如果使用了運(yùn)算函數(shù),查詢一樣會進(jìn)行全表的檢索。 

[[246445]] 

所以,我們可以改成這樣: 

  1. select * from Order where CreateTime > '2018-1-1 00:00:00' 

當(dāng)查詢允許Null值的列時,需要特別注意

我們在創(chuàng)建表的字段時,如果這個字段需要作為索引時,盡量不要允許Null。因為,單列索引不會存Null值,復(fù)合索引不存所有索引列都為Null的值,所以如果列允許為Null,可能會得到“不符合預(yù)期”的結(jié)果集。

例如:我們有一個User表,其中有UserName字段記錄了用戶的名字,并且添加了索引。

 

[[246446]]

[[246447]] 

現(xiàn)在我們執(zhí)行了這樣一個查詢: 

  1. select * from User where UserName != '小倩' 

但結(jié)果是這樣的 

[[246448]]  
[[246449]] 

那位UserName為Null的數(shù)據(jù)并沒有能包括進(jìn)來。因此,如果我們想要包含這個用戶的話,***能夠設(shè)置一個默認(rèn)值。

復(fù)合索引,使用時要注意順序

登錄,肯定是我們使用得最多的一個查詢了,為了保證效率,我們?yōu)長oginID和Password加上了復(fù)合索引。

當(dāng)我們使用 

  1. select * from User where LoginID = '{LoginID}' and Password = '{Password}'select * from User where Password = '{Password}' and LoginID = '{LoginID}' 

查詢時,都是能夠準(zhǔn)備的***索引。當(dāng)我們使用: 

  1. select * from User where LoginID = '{LoginID}' 

查詢時,也是能夠***索引的。但是,當(dāng)我們使用 

  1. select * from User where Password = '{Password}' 

查詢時,確無法***索引,這是什么原因呢?

這是由于,復(fù)合索引對于查詢的順序是非常的銘感的,所以,符合索引中包含了幾種規(guī)則,其中就有全列匹配和最左前綴匹配。

當(dāng)所有列都能夠匹配時,雖然查詢的順序上有不同,但是查詢優(yōu)化器會將順序進(jìn)行調(diào)整,以滿足適合索引的順序,所以,順序的顛倒是沒有問題的。 

[[246450]] 

但是,如果所有列不能匹配時,就必須滿足最左前綴匹配了,也就是,必須按照從左到右的順序進(jìn)行排列。因此,當(dāng)我們建立是索引是

結(jié)果唯一時,別悶著

通常,我們設(shè)計User表時,并不會把LoginID作為主鍵,但是,LoginID確會在業(yè)務(wù)邏輯中驗證唯一性,因此,如果使用 

  1. select * from User where LoginID = '{LoginID}' 

查詢時,結(jié)果一定只有一條。但是,數(shù)據(jù)庫是不知道的,即使找到了這唯一的一條結(jié)果,他也會一直繼續(xù),直到掃描完所有的數(shù)據(jù)。

因此,在執(zhí)行這樣的查詢時,我們可以優(yōu)化一下,改成: 

  1. select * from User where LoginID = '{LoginID}' limit 1 

這樣,當(dāng)查詢到結(jié)果時,就不會再繼續(xù)了。

***,上面所有的例子都是坑

盡量少用或別用Select *,我們的查詢其實都是有目的的,就好像登錄一樣,我們其實只需要知道有結(jié)果返回就行了,使用select count(0)就可以了,但是我們使用select * 的話,就會消耗大量無效的數(shù)據(jù)庫內(nèi)存。 

[[246451]]

 

責(zé)任編輯:龐桂玉 來源: 今日頭條
相關(guān)推薦

2019-11-28 18:51:07

PythonPHP編程語言

2014-12-11 13:41:32

2021-02-20 23:33:34

TypeScript代碼開發(fā)

2018-07-02 09:53:03

程序員代碼升職加薪

2021-12-30 16:40:47

iOS蘋果安卓

2012-01-03 18:50:53

iPhone

2022-09-11 15:02:21

JavaScriptTypeScript數(shù)據(jù)

2018-11-26 09:40:39

Python壞習(xí)慣編程語言

2010-04-08 13:06:02

Unix操作系統(tǒng)

2021-09-27 22:25:28

手機(jī)電池充電

2012-05-22 00:16:47

2009-07-21 14:32:02

IT人習(xí)慣

2009-07-20 14:02:49

66天習(xí)慣養(yǎng)成改正壞習(xí)慣

2019-11-22 09:16:32

跳槽那些事兒人工智能程序員

2012-07-17 11:13:44

程序員

2021-11-01 22:39:14

程序員專業(yè)技術(shù)

2021-01-01 14:37:51

SQL數(shù)據(jù)庫語言

2020-12-17 10:55:54

SQL數(shù)據(jù)庫語言

2018-01-11 13:57:36

程序員技能開發(fā)者

2013-01-22 11:57:29

IT工作者加班
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號