RiCo技術農場

執行計畫中有一個Number of Rows Read資訊，這篇我來簡單介紹一下

讓我們一起來瞧瞧，當我在(n)varchar類型欄位建立非叢集索引，SQL Server如何儲存

我在SQL效能調校課堂上有提到幾個常見查詢效能issues，

如不正確join type、謹慎使用MTVFs和低/高估記憶體大小，

現在SQL Server 2017可以更有效率自我修正這些效能問題。

SQL Server 2017提供自動調整功能，可以自動偵測執行計畫變更所造成的效能問題，

並自動(或手動)套用最佳執行計畫來修正效能問題，而Azure SQL Database則還多了自動索引管理，

可幫我們識別那些是重複索引、那些索引又可以刪除，

這項功能，我個人覺得，未來也會出現在SQL Server 2017。

SQL2014開始，Memory table的交易處理，有最大相依交易8的數量限制，只會發生在驗證和commit階段，

一般來說In-Memory的交易過程是非常短暫的，但這並不表示你的交易就不會失敗，

實務上，我一定會簡化Memory資料表相依(複雜)性，

雖然SQL2016 In-Memory table支援很多功能(FK、trigger、LOB..)，但這不代表一定有效率。

之前將old sp移轉至native compiled sp時，

執行SP有2點需要注意，因為對執行效能有一些影響。

Columnstore indexes主要可以改善大量scan/aggregate操作(可達10倍)，

因為採用xVelocity壓縮儲存方式(但無法對in-memory table壓縮)，

可大大節省disk space(壓縮大約10倍以上，取決於資料表中所有資料型別)，

所以和傳統row存放方式不同，通常會在fact table上建立來改善Data Mart/Data Warehouse彙熜效能。 

In-Memory table在Query performance方面表現如何呢?我用這篇來記錄我一些簡單測試。

之前我寫過一篇使用In-memory table variables來提高交易效能，這篇記錄當時一些額外測試。

Disk的checkpoint主要是將記憶體中的dirty pages和交易紀錄資訊寫入disk，

所以dirty pages的數量和checkpoint作業時間為線性關係，SQL Server會自動調整checkpoint作業頻率(預設60秒)，

這樣做是要降低其他應用程式所受到的效能影響，如果減少頻率，則會拉長完成時間，

增加頻率，則會影響效能(資料庫一般I/O活動會大幅增加)，

如果沒有特別理由，建議由SQL Server自行決定checkpoint頻率。

使用該選項時，請注意你的tempdb有足夠空間，並且也和User DB分開存放。

IN-Memory OLTP的Range Index使用類似B-tree的BW-tree結構，

透過BW-tree有效改善Range和point搜尋效率，並節省更多記憶體開銷，

尤其更適合DATE, DATETIME and DATETIME2。

I have wrote two articles about clustered index as below

[SQL SERVER][Memo]Clustered VS NonClustered Indexes

[SQL SERVER][Memo]再談 Clustered Index.

Today, I would like to talk about physically ordering or sorting of rows in clustered index.

SQL2016 In-Memory OLTP，現在可以讓我們很方便將資料存放至Memory table。

SQL2016新功能時態表我以前寫過兩篇，這功能去年我也正式使用在一個線上OLTP系統，

我得老實說這功能確實省下我不少時間，但往往方便就會忽略一些細節，

這篇紀錄一下和Memory table使用的情況。

我在超過20幾個的OLTP系統，啟用資料壓縮功能都不曾遇到吃掉系統大部分CPU資源，

不管是我在當DBA、consultant或developer角色時，只要使用企業版SQL SERVER，

我都會建議啟用資料壓縮功能。

No Join Predicate警告，是指出在這Query中，有存在無聯結述詞，那我們到底要不要在意這警告呢?

In recently, I tried to enhance performance of some operator api on our company system.

I found some operator api so fast on our system.

All queries using index seeks and no more than 3ms.

This post , I will show you how to improve its query performance.

I had known some tips for coding store procedure already.

Such as “don’t forget enable nocount”,”2 part names” ,”avoid prefix store procedure with sp_” and more…..

Today I will show you why don’t use sp_ as a prefix for store procedure and how to impact performance on the SQL server.

partition table對資料維護的效率是一直吸引我的主因，

透過switch partition可說秒殺insert+delete操作，

不僅lock request少，且又可降低交易紀錄檔使用量，整體對我來說好處不少，

但以前經驗告訴我，partition table影響insert和update效能，

我想如果這部分能使用In-Memory table來接管的話那真是太美妙了，可惜In-Memory table並不支援partition，

但我們依然可以透過SQL2016來模擬partition，讓我們同時享有高效率的資料維護和高效能的交易處理。