|
|
你真的了解“T-SQL邏輯查詢嗎?”提到的這種搜索方式，，也許很多人不明白（包括我，我看之前簡直感到詫異），很多都想 如果表的記錄有10000000～！#！@條，那每次的CROSS JOIN 將會長生 m*n的記錄，我們就假設(shè)是1W條 1w的平方還是有點點恐怖的，所以實際存儲引擎并不是如此查詢的，但是講清楚 邏輯查詢很重要，因為那是物理查詢的基礎(chǔ)，我覺得 理解數(shù)據(jù)庫引擎的查詢處理方式有助于 開發(fā)人員在生產(chǎn)過程中做出正確的選擇。PS：（有朋友說文章很多都“借鑒“別人的例子，我想是好東西用什么例子都不重要吧，只要能分享給大家，我抄都抄過來，再說是我對書的一些總結(jié)，呵呵～，這里要感謝作者Lubor Kollar，他是書中該章節(jié)的作者，是MS SQL SERVER 2005開發(fā)人員）。
那么開始吧，當(dāng)一個查詢你到達(dá)數(shù)據(jù)庫引擎的時候 ，SQL SERVER 執(zhí)行兩個主要的步驟來產(chǎn)生結(jié)果，一步就是 “查詢編譯”，一個是“生成查詢計劃”。首先提一下為什么存儲過程的效率總是比應(yīng)用程序級別的T-SQL語句來的更迅速，首先拋開網(wǎng)絡(luò)傳輸T-SQL語句的時間不管，我們利用應(yīng)用程序發(fā)送的T-SQL語句，交個數(shù)據(jù)庫執(zhí)行，他首先就要對T-SQL語句進(jìn)行編譯，在SQL中編譯的概念，和我們寫應(yīng)用程序理解應(yīng)該是一致的，包括語法的檢查，代數(shù)化以及查詢優(yōu)化，就像我們的應(yīng)用程序（我是搞.NET的），編譯器對你的C#代碼進(jìn)行編譯，先檢查語法的錯誤，然后生成dll，dll 中就包括對整個類庫的描述類似于SQL中的執(zhí)行計劃，回到SQL中，這個編譯過程當(dāng)然是需要時間的，所以應(yīng)用程序級別的T-SQL 交給數(shù)據(jù)庫編譯以后才執(zhí)行，更可惡的是，竟然對外部傳輸來的T-SQL語句不會進(jìn)行 “過程緩存”，因為他在編譯后就立即執(zhí)行了，而存儲過程他就已經(jīng)預(yù)先編譯了，也進(jìn)行了查詢的優(yōu)化了，還會保存在“過程緩存”中，所以推薦使用存儲過程。
下面就來展示一個例子：
USE Northwind;
SELECT C.CustomerId,COUNT(o.OrderId) AS NumOrders
FROM dbo.Customers AS C
LEFT OUTER JOIN dbo.Orders AS o ON c.CustomerId=o.CustomerId
WHERE c.City='London'
GROUP BY C.CustomerId
HAVING COUNT(o.OrderId)>5
ORDER BY NumOrders;
返回結(jié)果:
EASTC 8
SEVES 9
BSBEV 10
AROUT 13
上次 就有朋友在留言中提到這個問題 ,下面我們來看看他的執(zhí)行計劃,到底 邏輯處理 和物理處理 有什么不同.我們點擊 “顯示估計的執(zhí)行計劃” ,然后找到 最右邊的 Index seek 索引查找,下圖
這是我切下來的圖片,
我們看到 他的Seek 謂詞 是 [Northwind].[dbo].[Customers].City=N’London’
再看看 我們的查詢 語句的WHERE 部分
WHERE c.City='London'
完全 符合我在 你真的了解T-SQL邏輯查詢嗎? 一問中先說到的 第一個階段 找到FROM 的表,但是又有一點不同,物理查詢 他會等到執(zhí)行CROSS 鏈接以后的 記錄,他會先直接 篩選WHERE 中的記錄 等于 講 前3個 邏輯 處理階段 的 連接和 第4個階段WHERE 合并了.至于 這樣有什么好處呢?
我們繼續(xù),首先我們分析 WHERE ,我們先考慮一種情況 如果 是按照 邏輯 執(zhí)行階段的順序,CROSS JOIN 下來的 虛擬表 將是非常恐怖的 .可是 MS 的員工 在邏輯階段 到物理階段的過程中,肯定會采取一些列手段來優(yōu)化T-SQL 語句,所以 我們聯(lián)想到 先執(zhí)行WHERE 中的 邏輯處理階段 將 左表中的 結(jié)果 返回
相當(dāng)于 執(zhí)行:
USE Northwind;
SELECT C.CustomerId
FROM dbo.Customers AS C
WHERE c.City='London'
他返回的結(jié)果是:
AROUT
BSBEV
CONSH
EASTC
NORTS
SEVES
果然和我們 預(yù)想的一樣返回的 行數(shù) 完全和執(zhí)行計劃中的 估計行數(shù) : 6 行 吻合,
這樣執(zhí)行的結(jié)果的好處 ,我們自然可以聯(lián)想到,將6行的結(jié)果集 再來 CROSS JOIN 就小多了
,下面我們繼續(xù)剛才的分析,接著 自然是 Orders 表的鏈接,
自然 就
啟用它的ON 條件, (看看Seek 謂詞)
我們再回過來看看 之前說的 物理處理階段,是不是 完全吻合. 之所以要說明白 邏輯階段,(說個題外話,有興趣的朋友可以去看看Algebrizer,他是T-SQL中的 新組件是 綁定的重要功能,我想對高數(shù)有研究的朋友可能會喜歡里面的研究和分析.他取代了2000中的Normalizer組件,在物理 邏輯 級別提高了T-SQL 效率.)
對于 后面文章的 優(yōu)化查詢語句 起到了 舉足輕重的作用,在 講明了 物理 處理階段和 邏輯處理階段 對于 存儲引擎是 怎么執(zhí)行T-SQL的 有了一定的了解,才能從原理級別去提高T-SQL ,這也是國內(nèi)很多同行不曾重視的.當(dāng)然本文的下一篇將繼續(xù)我們的研究 -子查詢的精要
it知識庫：MS SQL Server 2005 物理查詢處理中的各個階段(二)，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
