Rock的SQL筆記本

日前在Tunning一句語法時，在SSMS的視窗下撰寫TSQL測試。當時發現我用變數當參數來查跟直接用數字來當參數查時會跑不同的執行計畫，Code的範例如下

很久以前就聽聞過SQL的計畫指南功能，但我一直沒有用過。可以從字面上初步了解就是針對某些查詢我們可以干涉最佳化引擎，讓SQL根據我們的需求來跑執行計畫。一些官方文件的舉例就是在不異動查詢語句的狀況下讓管理者可以針對語句下hint(如MAXDOP設定及OPTIMIZE FOR或Recompile等)。

最近由於SQL2008R2即將EOS，所以陸陸續續將資料庫升級到SQL2017的版本。而升級完成後有部分功能居然查詢時間太久導致Web TimeOut，經一番查詢後發現是新版SQL Server已在SQL2014採用新的基數估計(Cardinality Estimation簡稱CE)。而某些查詢會因為採用新版CE來估計統計反而誤用效能不好的執行計畫，官網分析有下列特性的查詢就可能發生查詢變慢的狀況。

相信很多情境下會在資料表的欄位設計上用到所謂的計算欄位(Computed Column)，顧名思義該欄位存放的值就是經過計算的一個結果。然而計算欄位的資料內容一般常會是取出資料後即時運算並顯示結果，但有時候也會因為某些需求希望能將運算結果真實寫入在page中，而這個需求只要在建立資料欄位時加入一個關鍵字Persisted即可。

日前檢視一支StoreProcedure時無意間發現了這一個問題。當時該SP的開發者在該SP中利用User丟進來的參數來串成他要的Query字串後再透過sp_executesql執行該語法字串。等於是在SP中組出一個Adhoc字串來跑，這樣完全無法享受到重用執行計畫的好處。

今天Alter一張千萬筆的資料表中一個欄位為NOT NULL，結果爆了LDF 

日跟有位PASS好友聊到當他分批大量刪除資料時會有Blocking造成，因此他想在delete的時候加入rowlock hint來減少Blocking的發生。
他表示delete的where條件式並沒有索引可以用，我當下是建議可以建立合適索引後再來刪資料，資料刪得快相對也比較不會發生Blocking了。

一直以來，很多文章或書籍都會提到資料庫在對資料做增刪修都會因為資料異動導致Page Splits的產生。一旦過度的分割就會提高所謂的邏輯片段，而要降低邏輯片段就得對資料表或索引做Rebuild或Reorganize，今天心血來潮突然想LAB看看SQL對Page Splits的運作原理為何，所以簡易做個實驗。

今天檢視前一日的SQL 效能報表時發現下班前到晚上8點持續有BatchRequest偏高的趨勢

現實的資料規劃中常會遇到有人將一些有意義的代號組成一字串來儲存，這樣的設計模式常常會碰到的大問題就是需要拆字串來查詢。而拆字串的方式查詢往往都無法使用索引，因此造成Table Scan進而影響效能。

MSDN官網在Create Index中對DROP_EXISTING功能的解說如下。

建立外鍵Foreign Key可以確保關聯式資料表的資料的完整性，避免掉孤兒資料的產生。

日前PASS好友說到一個特殊情況，他們工程師用SSMS的匯出匯入精靈到資料時，網路傳輸只衝到20MB左右。同樣的作業改用SSIS來跑，網路傳輸可以衝到80MB。

之前有寫過一篇如何在大量Insert資料的交易中降低交易紀錄的成長呢? 其中有提到幾種降低交易紀錄量的寫入模式..

老實說我並不知道，直到今天看到一本SQL管理書籍中寫到，才知道sp_configure居然有這樣的可怕因子

Order By向來是為人垢弊的效能殺手，可是有時又不得排序，也許可以透過建立索引來降低效能的影響。

日前有一個系統功能是要大量更新資料表的資料，我詢問一下PG預計如何撰寫該功能。PG回覆我說就是用迴圈更新前端餵近來的資料，我聽到當下覺得這樣的做法效能不僅差，且會對SQL造成一定程度的效能影響。

日前到淡江上許致學老師的效能調教課程，課程中聽到老師提到SQL的資料表壓縮功能會耗用CPU效能，但不會造成明顯的效能問題。因此很好奇的實測看看，到底壓縮過的資料會造成CPU多大的影響呢?

SQL在做索引操作時(重建或重組)往往需耗費很多的交易紀錄空間，今天無意間看見微軟的一張圖表，可以讓我們了解在對大資料表做索引操作時用甚麼樣的還原模式是最不耗資源的。

之前聽課時常聽講師提及一些可以提高特定查詢效能的作法，例如計畫指南或索引檢視。今天實作一下索引檢視並記錄一下，分享給大家 !