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

聚集索引掃描

SELECT * FROM C_SY_Ownedstorm 

聚集索引掃描比表掃描快

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

表掃描

SELECT *  FROM #temp 

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

測試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 

哈希匹配：

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

有缺失或者不正確的索引

缺少where字句

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

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

聚集索引查找：

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

排序：

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

select * from t1 
 order by desc 

循環(huán)嵌套

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

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

合并連接

合并連接也是在讀的同時對兩個存儲輸入的一行進行比較。在每個步驟中，比較每個輸入的下一行。如果兩行是相同，輸出一個連接后的行并繼續(xù)。如果行是不同的，舍棄兩個輸入行中較少的那個并繼續(xù)。因為輸入是存儲，連接舍棄的任何行必須比兩個輸入中任何剩下的行要小，因此可以永不連接。合并連接不需要對兩個輸入中的每一行掃描。只要到了兩個輸入中的某一個的末尾，合并連接就會停止掃描。

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

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

最新評論