国产最新自拍网站,北岛玲一区二区三区,久久视频这里只有精品

主頁(yè) > 知識(shí)庫(kù) > MSSQL優(yōu)化之探索MSSQL執(zhí)行計(jì)劃（轉(zhuǎn)）

MSSQL優(yōu)化之探索MSSQL執(zhí)行計(jì)劃（轉(zhuǎn)）

網(wǎng)上的SQL優(yōu)化的文章實(shí)在是很多，說(shuō)實(shí)在的，我也曾經(jīng)到處找這樣的文章，什么不要使用IN了，什么OR了，什么AND了，很多很多，還有很多人拿出僅幾S甚至幾MS的時(shí)間差的例子來(lái)證明著什么(有點(diǎn)可笑)，讓許多人不知道其是對(duì)還是錯(cuò)。而SQL優(yōu)化又是每個(gè)要與數(shù)據(jù)庫(kù)打交道的程序員的必修課，所以寫(xiě)了此文，與朋友們共勉。
談到優(yōu)化就必然要涉及索引，就像要講鎖必然要說(shuō)事務(wù)一樣，所以你需要了解一下索引，僅僅是索引，就能講半天了，所以索引我就不說(shuō)了(打很多字是很累的，況且我也知之甚少)，可以去參考相關(guān)的文章，這個(gè)網(wǎng)上資料比較多了。
今天來(lái)探索下MSSQL的執(zhí)行計(jì)劃，來(lái)讓大家知道如何查看MSSQL的優(yōu)化機(jī)制，以此來(lái)優(yōu)化SQL查詢(xún)。

復(fù)制代碼代碼如下:

 
--DROP TABLE T_UserInfo---------------------------------------------------- 
--建測(cè)試表 
CREATE TABLE T_UserInfo 
( 
Userid varchar(20), UserName varchar(20), 
RegTime datetime, Tel varchar(20), 
) 
--插入測(cè)試數(shù)據(jù) 
DECLARE @I INT 
DECLARE @ENDID INT 
SELECT @I = 1 
SELECT @ENDID = 100 --在此處更改要插入的數(shù)據(jù)，重新插入之前要?jiǎng)h掉所有數(shù)據(jù) 
WHILE @I = @ENDID 
BEGIN 
INSERT INTO T_UserInfo 
SELECT 'ABCDE'+CAST(@I AS VARCHAR(20))+'EF','李'+CAST(@I AS VARCHAR(20)), 
GETDATE(),'876543'+CAST(@I AS VARCHAR(20)) 
SELECT @I = @I + 1 
END 

--相關(guān)SQL語(yǔ)句解釋
---------------------------------------------------------------------------
--建聚集索引
CREATE CLUSTERED INDEX INDEX_Userid ON T_UserInfo (Userid)
--建非聚集索引
CREATE NONCLUSTERED INDEX INDEX_Userid ON T_UserInfo (Userid)
--刪除索引
DROP INDEX T_UserInfo.INDEX_Userid
---------------------------------------------------------------------------
---------------------------------------------------------------------------
--顯示有關(guān)由Transact-SQL 語(yǔ)句生成的磁盤(pán)活動(dòng)量的信息
SET STATISTICS IO ON
--關(guān)閉有關(guān)由Transact-SQL 語(yǔ)句生成的磁盤(pán)活動(dòng)量的信息
SET STATISTICS IO OFF
--顯示[返回有關(guān)語(yǔ)句執(zhí)行情況的詳細(xì)信息，并估計(jì)語(yǔ)句對(duì)資源的需求]
SET SHOWPLAN_ALL ON
--關(guān)閉[返回有關(guān)語(yǔ)句執(zhí)行情況的詳細(xì)信息，并估計(jì)語(yǔ)句對(duì)資源的需求]
SET SHOWPLAN_ALL OFF
---------------------------------------------------------------------------
請(qǐng)記住：SET STATISTICS IO 和 SET SHOWPLAN_ALL 是互斥的。
OK，現(xiàn)在開(kāi)始：
首先，我們插入100條數(shù)據(jù)
然后我寫(xiě)了一個(gè)查詢(xún)語(yǔ)句：
SELECT * FROM T_UserInfo WHERE USERID='ABCDE6EF'
選中以上語(yǔ)句，按Ctrl+L，如下圖
這就是MSSQL的執(zhí)行計(jì)劃：表掃描：掃描表中的行
然后我們來(lái)看該語(yǔ)句對(duì)IO的讀寫(xiě)：
執(zhí)行:SET STATISTICS IO ON
此時(shí)再執(zhí)行該SQL:SELECT * FROM T_UserInfo WHERE USERID='ABCDE6EF'
切換到消失欄顯示如下：
表'T_UserInfo'。掃描計(jì)數(shù)1，邏輯讀1 次，物理讀0 次，預(yù)讀0 次。
解釋下其意思：
四個(gè)值分別為：
執(zhí)行的掃描次數(shù);
從數(shù)據(jù)緩存讀取的頁(yè)數(shù);
從磁盤(pán)讀取的頁(yè)數(shù);
為進(jìn)行查詢(xún)而放入緩存的頁(yè)數(shù)
重要：如果對(duì)于一個(gè)SQL查詢(xún)有多種寫(xiě)法，那么這四個(gè)值中的邏輯讀(logical reads)決定了哪個(gè)是最優(yōu)化的。

接下來(lái)我們?yōu)槠浣ㄒ粋€(gè)聚集索引
執(zhí)行CREATE CLUSTERED INDEX INDEX_Userid ON T_UserInfo (Userid)
然后再執(zhí)行SELECT * FROM T_UserInfo WHERE USERID='ABCDE6EF'
切換到消息欄如下顯示：
表'T_UserInfo'。掃描計(jì)數(shù)1，邏輯讀2 次，物理讀0 次，預(yù)讀0 次。
此時(shí)邏輯讀由原來(lái)的1變成2，
說(shuō)明我們又加了一個(gè)索引頁(yè)，現(xiàn)在我們查詢(xún)時(shí)，邏輯讀就是要讀兩頁(yè)(1索引頁(yè)+1數(shù)據(jù)頁(yè))，此時(shí)的效率還不如不建索引。
此時(shí)再選中查詢(xún)語(yǔ)句，然后再Ctrl+L，如下圖:

聚集索引查找：掃描聚集索引中特定范圍的行
說(shuō)明，此時(shí)用了索引。
OK,到這里你應(yīng)該已經(jīng)知道初步知道MSSQL查詢(xún)計(jì)劃和如何查看對(duì)IO的讀取消耗了吧！

接下來(lái)我們繼續(xù)：

現(xiàn)在我再把測(cè)試數(shù)據(jù)改變成1000條
再執(zhí)行SET STATISTICS IO ON,再執(zhí)行
SELECT * FROM T_UserInfo WHERE USERID='ABCDE6EF'
在不加聚集索引的情況下：
表'T_UserInfo'。掃描計(jì)數(shù)1，邏輯讀7 次，物理讀0 次，預(yù)讀0 次。
在加聚集索引的情況下：CREATE CLUSTERED INDEX INDEX_Userid ON T_UserInfo (Userid)
表'T_UserInfo'。掃描計(jì)數(shù)1，邏輯讀2 次，物理讀0 次，預(yù)讀0 次。
(其實(shí)也就是說(shuō)此時(shí)是讀了一個(gè)索引頁(yè)，一個(gè)數(shù)據(jù)頁(yè))
如此，在數(shù)據(jù)量稍大時(shí)，索引的查詢(xún)優(yōu)勢(shì)就顯示出來(lái)了。

先小總結(jié)下：
當(dāng)你構(gòu)建SQL語(yǔ)句時(shí)，按Ctrl+L就可以看到語(yǔ)句是如何執(zhí)行，是用索引掃描還是表掃描？
通過(guò)SET STATISTICS IO ON 來(lái)查看邏輯讀，完成同一功能的不同SQL語(yǔ)句，邏輯讀
越小查詢(xún)速度越快(當(dāng)然不要找那個(gè)只有幾百條記錄的例子來(lái)反我)。

我們?cè)倮^續(xù)深入：
OK，現(xiàn)在我們?cè)賮?lái)看一次，我們換個(gè)SQL語(yǔ)句，來(lái)看下MSSQL如何來(lái)執(zhí)行的此SQL呢？
現(xiàn)在去掉索引：DROP INDEX T_UserInfo.INDEX_Userid
現(xiàn)在打開(kāi)[顯示語(yǔ)句執(zhí)行情況的詳細(xì)信息]：SET SHOWPLAN_ALL ON
然后再執(zhí)行：SELECT * FROM T_UserInfo WHERE USERID LIKE 'ABCDE8%'
看結(jié)果欄：結(jié)果中有些具體參數(shù)，比如IO的消耗，CPU的消耗。
在這里我們只看StmtText:
SELECT * FROM T_UserInfo WHERE USERID LIKE 'ABCDE8%'
|--Table Scan(OBJECT:([student].[dbo].[T_UserInfo]), WHERE:(like([T_UserInfo].[Userid], 'ABCDE8%', NULL)))
Ctrl+L看下此時(shí)的圖行執(zhí)行計(jì)劃：

我再加上索引：
先關(guān)閉：SET SHOWPLAN_ALL OFF
再執(zhí)行：CREATE CLUSTERED INDEX INDEX_Userid ON T_UserInfo (Userid)
再開(kāi)啟：SET SHOWPLAN_ALL ON
再執(zhí)行：SELECT * FROM T_UserInfo WHERE USERID LIKE 'ABCDE8%'
查看StmtText:
SELECT * FROM T_UserInfo WHERE USERID LIKE 'ABCDE8%'
|--Clustered Index Seek(OBJECT:([student].[dbo].[T_UserInfo].[INDEX_Userid]), SEEK:([T_UserInfo].[Userid] >= 'ABCDE8' AND [T_UserInfo].[Userid] 'ABCDE9'), WHERE:(like([T_UserInfo].[Userid], 'ABCDE8%', NULL)) ORDERED FORWARD)Ctrl+L看下此時(shí)的圖行執(zhí)行計(jì)劃：
Ctrl+L看下此時(shí)的圖行執(zhí)行計(jì)劃：

在有索引的情況下，我們?cè)賹?xiě)一個(gè)SQL：
SET SHOWPLAN_ALL ON
SELECT * FROM T_UserInfo WHERE LEFT(USERID,4)='ABCDE8%'
查看StmtText:
SELECT * FROM T_UserInfo WHERE LEFT(USERID,4)='ABCDE8%'
|--Clustered Index Scan(OBJECT:([student].[dbo].[T_UserInfo].[INDEX_Userid]), WHERE:(substring([T_UserInfo].[Userid], 1, 4)='ABCDE8%'))
Ctrl+L看下此時(shí)的圖行執(zhí)行計(jì)劃：

我們?cè)俜謩e看一下三種情況下對(duì)IO的操作
分別如下：
第一種情況：表'T_UserInfo'。掃描計(jì)數(shù)1，邏輯讀7 次，物理讀0 次，預(yù)讀0 次。
第二種情況：表'T_UserInfo'。掃描計(jì)數(shù)1，邏輯讀3 次，物理讀0 次，預(yù)讀0 次。
第三種情況：表'T_UserInfo'。掃描計(jì)數(shù)1，邏輯讀8 次，物理讀0 次，預(yù)讀0 次。
這說(shuō)明:
第一次是表掃描，掃了7頁(yè)，也就是全表掃描
第二次是索引掃描，掃了1頁(yè)索引，2頁(yè)數(shù)據(jù)頁(yè)
第三次是索引掃描+表掃描，掃了1頁(yè)索引，7頁(yè)數(shù)據(jù)頁(yè)
[圖形界面也有對(duì)CPU和IO的消耗，也可以看出來(lái)哪個(gè)最優(yōu)!]

通過(guò)比較，嘿嘿，很容易的看出：第二種第三種寫(xiě)法在都有索引的情況下，like有效的使用索引，而left則不能，這樣一個(gè)最簡(jiǎn)單的優(yōu)化的例子就出來(lái)了，哈哈。

如果以上你都明白了，那么你可能已經(jīng)對(duì)SQL的優(yōu)化有初步新的想法了，網(wǎng)上一堆堆的SQL優(yōu)化的文章真的是那樣嗎？你自己試試就知道了，而不必盲目去記那些東西，自己試試，看看MSSQL到底是怎么來(lái)執(zhí)行就明白了。
在我舉的例子中，用的是聚集索引掃描，字段是字母加數(shù)字，大家可以試試看純數(shù)字的、字母的、漢字的等等，了解下MMSQL會(huì)如何改變SQL語(yǔ)句來(lái)利用索引。然后再試試非聚集索引是什么情況？用不用索引和什么有關(guān)？子查詢(xún)MSSQL是如何執(zhí)行？IN用不用索引，LIKE用不用索引？函數(shù)用不用索引？OR、AND、UNION？子查詢(xún)呢？在這里我不一一去試給大家看了，只要知道了如何去看MSSQL的執(zhí)行計(jì)劃（圖形和文本)，很多事情就很明朗了。

大總結(jié)：
實(shí)現(xiàn)同一查詢(xún)功能的SQL寫(xiě)法可能會(huì)有多種，如果判斷哪種最優(yōu)化，如果僅僅是從時(shí)間上來(lái)測(cè)，會(huì)受很多外界因素的影響，而我們明白了MSSQL如何去執(zhí)行，通過(guò)IO邏輯讀、通過(guò)查看圖示的查詢(xún)計(jì)劃、通過(guò)其優(yōu)化后而執(zhí)行的SQL語(yǔ)句，才是優(yōu)化SQL的真正途徑。

另外提醒下：數(shù)據(jù)量的多少有時(shí)會(huì)影響MSSQL對(duì)同一種查詢(xún)寫(xiě)法語(yǔ)句的執(zhí)行計(jì)劃，這一點(diǎn)在非聚集索引上特別明顯，還有就是在多CPU與單CPU下，在多用戶(hù)并發(fā)情況下，同一寫(xiě)法的查詢(xún)語(yǔ)句執(zhí)行計(jì)劃會(huì)有所不同，這個(gè)就需要大家有機(jī)會(huì)去試驗(yàn)了(我也沒(méi)有這方面的太多經(jīng)驗(yàn)與大家分享)。

先寫(xiě)這些吧，由于我對(duì)MSSQL認(rèn)識(shí)還很淺薄，如有不對(duì)的地方，還請(qǐng)指正。

標(biāo)簽：鹽城本溪朔州通化宜春邢臺(tái) 巴彥淖爾遼源

巨人網(wǎng)絡(luò)通訊聲明：本文標(biāo)題《MSSQL優(yōu)化之探索MSSQL執(zhí)行計(jì)劃（轉(zhuǎn)）》，本文關(guān)鍵詞 MSSQL,優(yōu)化,之,探索,執(zhí)行,；如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問(wèn)題，煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們，我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò)，涉及言論、版權(quán)與本站無(wú)關(guān)。