Rock的SQL筆記本

本次參加PASS Taiwan Summit 2022時和朋友討論到多檔案的File Group是如何分散存放資料，其分散的最小單位為何呢?

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

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

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

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

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

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

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

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

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

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

一直以來在寫TSQL時如需要一個暫存資料表，大多會用Table Varible或Temp Table來做

但常常聽到一些講師或看見官方文件都將Table Varible定義成存放小資料量的臨時資料表

但我長期使用Table Varible來做大資料的暫存表也沒遇見什大問題，因此也就沒多注意。

直到某天突然爆了一個大雷......

針對大量資料寫入資料表的動作其很大的副作用就是交易紀錄檔的成長

因此在做樣大量寫入資料的動作時，如何減少交易紀錄的成長變是很重要的課題。