SQL Server里簡單參數化的痛苦
在今天的文章里,我想談下對于即席SQL語句(ad-hoc SQL statements),SQL Server使用的簡單參數化(Simple Parameterization)的一些特性和副作用。首先,如果你的SQL語句包含這些,簡單參數化不會發生:
- JOIN
- IN
- BULK INSERT
- UNION
- INTO
- DISTINCT
- TOP
- GROUP BY
- HAVING
- COMPUTE
- Sub Queries
一般來說,如果你處理所謂的安全執行計劃(Safe Execution Plan),SQL Server自動參數化你的SQL語句:不管提供的參數值,查詢總必須通向一樣的執行計劃。如果你的執行計劃里有書簽查找,這就是不可能的例子。因為臨界點定義了是否進行書簽查找還是全表/聚集索引掃描。
自動參數化并不那么酷!
如果SQL Server能自動參數化你的SQL語句,你還是要考慮下SQL Server引入的自動參數化SQL語句的一些副作用。我們來看一個具體的例子。下列查詢創建一個表,執行一個會被SQL Server自動參數化的簡單SQL語句。
- -- Create a simple table
- CREATE TABLE Orders
- (
- Col1 INT IDENTITY(1, 1) PRIMARY KEY NOT NULL,
- Price DECIMAL(18, 2)
- )
- GO
- -- This query gets auto parametrized, because it is a simple query with a safe (consistent) plan
- SELECT * FROM Orders
- WHERE Price = 5.70
- GO
- -- Analyze the Plan Cache
- SELECT
- st.text,
- qs.execution_count,
- cp.cacheobjtype,
- cp.objtype,
- cp.*,
- qs.*,
- p.*
- FROM sys.dm_exec_cached_plans cp
- CROSS APPLY sys.dm_exec_query_plan(cp.plan_handle) p
- CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) st
- LEFT JOIN sys.dm_exec_query_stats qs ON qs.plan_handle = cp.plan_handle
- WHERE st.text LIKE '%Orders%'
- GO
然后當你查看計劃緩存時,你會看到SQL Server能為你自動參數化SQL語句:
- (@1 numeric(3,2))SELECT * FROM [Orders] WHERE [Price]=@1
但什么是選擇的作為參數的數據類型?最小可能的那個!在這里是NUMERIC(3,2)!如果現在你執行下列2個查詢:
- -- Execute a slightly different query
- SELECT * FROM Orders
- WHERE Price = 8.70
- GO
- -- Execute a slightly different query
- SELECT * FROM Orders
- WHERE Price = 124.50
- GO
SQL Server能重用為第1個使用8.7值SQL語句的參數化SQL語句的執行計劃。但用124.50值的第2個SQL語句呢?對于這個SQL語句緩存的計劃不能被重用,因為124.50值不符合NUMERIC(3,2)。在這個情況下,SQL Server用NUMERIC(5,2)數據類型生成你SQL語句的新參數化版本。你剛用你的SQL語句的額外的參數化版本污染了你的計劃緩存!當你執行下列語句會變得更糟:
- -- Execute a slightly different query
- SELECT * FROM Orders
- WHERE Price = 1204.50
- GO
這個會再次給你新的用NUMERIC(6,2)數據類型的新參數化版本——計劃緩存里另一個版本!當我展示這個行為的時候,很多人都建議我應該用逆序來執行剛才的SQL語句。我們通過首先清空計劃緩存來試下。
- -- Clear the Plan Cache
- DBCC FREEPROCCACHE
- GO
- -- Execute a slightly different query
- SELECT * FROM Orders
- WHERE Price = 1204.50
- GO
- -- Execute a slightly different query
- SELECT * FROM Orders
- WHERE Price = 124.50
- GO
- -- Execute a slightly different query
- SELECT * FROM Orders
- WHERE Price = 8.70
- GO
然后當你看計劃緩存時,沒有任何改變:SQL Server還生成了3個不同的參數化SQL語句——每次都用最小可能的數據類型。你怎么做沒有一點關系,即你執行你SQL語句的順序:在自動參數化期間,SQL Server總會選擇最小可能的數據類型。當你依賴SQL Server這個特性時,好好考慮下。
VARCHAR如何呢?SQL Server自動參數化包含字符值(例如VARCHAR)的SQL語句時,事情會好點。假設有下列表定義和下列2個查詢:
- -- Create another table to demonstrate this problem
- CREATE TABLE Orders3
- (
- Col1 INT IDENTITY(1, 1) PRIMARY KEY NOT NULL,
- Col2 VARCHAR(100)
- )
- GO
- -- Clears the Plan Cache
- DBCC FREEPROCCACHE
- GO
- -- A VARCHAR/CHAR column is always auto parametrized to a VARCHAR(8000)
- SELECT * FROM Orders3
- WHERE Col2 = 'Woody'
- GO
- -- A VARCHAR column is always auto parametrized to a VARCHAR(8000)
- SELECT * FROM Orders3
- WHERE Col2 = 'Tu'
- GO
在這個情況下,SQL Server用VARCHAR(8000)生成1個自動參數化SQL語句——***可能的數據類型。從剛才例子里,這是你所期待的行為。有時SQL Server好事壞事同時做……
小結
當你和簡單SQL語句打交道時,自動參數化可以非常棒。但如你在這個文章里所見,你要知道SQL Server引入的副作用。另外SQL Server的簡單參數化特性還會提供你強制參數化(Forced Parameterization)功能,這個我會在以后的文章里介紹。
注:此文章為WoodyTu學習MS SQL技術,收集整理相關文檔撰寫,歡迎轉載,但未經作者同意必須保留此段聲明,且在文章頁面明顯位置給出此文鏈接!