在本文中，小編將與大家重點(diǎn)探討SQL執(zhí)行進(jìn)展優(yōu)化的方法。

聚集索引掃描

SELECT * FROM C_SY_Ownedstorm 

聚集索引掃描比表掃描快

聚集索引掃描：發(fā)生于聚集表，也相當(dāng)于全表掃描操作，但在針對聚集列的條件等操作時(shí)，效率會較好。

表掃描

SELECT *  FROM #temp 

表掃描:發(fā)生于堆表，并且沒有可用的索引時(shí)，會發(fā)生表掃描,表示整個(gè)表掃描一次。

測試SQL

CREATE TABLE t1(c1 INT, c2 VARCHAR (8000)); 
 
 GO 
 
 DECLARE @a INT; 
 
 SELECT @a = 1; 
 
 WHILE (@a = 5000) 
 
 BEGIN       
 
   INSERT INTO t1 VALUES (@a, replicate('a', 5000)) 
 
   SELECT @a = @a + 1 
 
 END 
 
 GO 
SELECT count(1) FROM t1 
 
group by c1 

哈希匹配：

哈希匹配的作用就是把它右側(cè)的兩個(gè)表中行數(shù)比較少的那個(gè)經(jīng)過哈希算法形成一個(gè)哈希表，然后再有另一個(gè)數(shù)據(jù)行數(shù)比較大的表來之前形成的哈希表中匹配查找數(shù)據(jù)，大體上就是這個(gè)么流程。但是哈希匹配操作的出現(xiàn)一定要提高我們的警惕，當(dāng)哈希匹配右側(cè)的兩個(gè)表中的數(shù)據(jù)有一個(gè)比另一個(gè)明顯的少的時(shí)候，哈希匹配的效率會比較高，反之就會影響效率。出現(xiàn)哈希匹配大概有這么幾個(gè)情況：

有缺失或者不正確的索引

缺少where字句

在where子句中有對列的類型轉(zhuǎn)換或者數(shù)據(jù)操作，這樣就不能使用索引了

雖說哈希匹配在某些情況下效率會比較高，但是這并不意味著沒有更好的來提高這個(gè)查詢的效率，比如添加適當(dāng)?shù)乃饕蛘咄ㄟ^where語句來減少數(shù)據(jù)量等方法。換句話說，當(dāng)出現(xiàn)哈希匹配這個(gè)操作的時(shí)候，我們要引起注意，看看是否還有別的方法來提高查詢效率，如果沒有的話，或許哈希匹配就是最好的選擇了。

聚集索引查找：

CREATE UNIQUE CLUSTERED INDEX _Id 
 
ON t1(c1) 
 
select * from t1 
 
where c1=3 

排序：

排序是消耗性能的，sql server中排序是在數(shù)據(jù)找出來以后在進(jìn)行排序的。

select * from t1 
 order by desc 

循環(huán)嵌套

對于使用簡單內(nèi)連接的小數(shù)據(jù)量表，嵌套循環(huán)是最佳策略。最適合兩個(gè)表的記錄數(shù)差別非常大，并且在連接的列上都有索引的情況。嵌套循環(huán)連接所需的I/O和比較都是最少的。

嵌套循環(huán)在外表（往往是小數(shù)據(jù)量的表）中每次循環(huán)一個(gè)記錄，然后在內(nèi)表中查找所匹配的記錄并輸出。有很多關(guān)于嵌套循環(huán)策略的名字。例如，對整個(gè)表或索引進(jìn)行查詢，稱為Naive（無知的）嵌套循環(huán)連接。使用正常索引或臨時(shí)索引時(shí)，被稱為索引嵌套循環(huán)連接或臨時(shí)索引嵌套循環(huán)連接。

合并連接

合并連接也是在讀的同時(shí)對兩個(gè)存儲輸入的一行進(jìn)行比較。在每個(gè)步驟中，比較每個(gè)輸入的下一行。如果兩行是相同，輸出一個(gè)連接后的行并繼續(xù)。如果行是不同的，舍棄兩個(gè)輸入行中較少的那個(gè)并繼續(xù)。因?yàn)檩斎胧谴鎯ΓB接舍棄的任何行必須比兩個(gè)輸入中任何剩下的行要小，因此可以永不連接。合并連接不需要對兩個(gè)輸入中的每一行掃描。只要到了兩個(gè)輸入中的某一個(gè)的末尾，合并連接就會停止掃描。

嵌套循環(huán)連接總的消耗和在輸入表中行的乘積成比例，不同于嵌套循環(huán)連接，合并連接的表最多讀一次，總的消耗和輸入行數(shù)的總數(shù)成正比例，因此何必連接對于大量的輸入是較好的選擇。

以上就是小編對SQL執(zhí)行進(jìn)展優(yōu)化方法進(jìn)行的總結(jié)，希望大家能有所收獲。