SQL Server On Linux（19）—— SQL Server On Linux效能（5）——針對性能的配置（資料庫層面）
本人新書上市，請多多關照： 《SQL Server On Linux運維實戰 2017版從入門到精通》
在配置完例項層面之後，就可以進行資料庫層面的配置。例項層面使用的是ALTER SERVER，而資料庫層面的配置使用的就是ALTER DATABASE這個T-SQL命令。
通常來說，資料庫配置的內容集中在下圖的【選項】部分
如上圖，分為強制和簡單兩種選項，上一文提到的對ad hoc（即席查詢）的plan cache優化的其中一個原因是它們並沒有引數化。沒有引數化會導致針對不同的SQL語句建立獨立的執行計劃並快取。對於這個選項，SQL Server預設使用簡單模式，但是簡單模式當然無法應對絕大部分的情況，所以可以使用上圖的圖形化介面或者ALTER DATABASE SET PARAMETERIZATION FORCED。
那在什麼時候應該使用強制呢？可以參考一些指標，如sys.dm_os_performance_counters中where object_name = SQLServer:SQL Statistics and counter_name = SQL Compilations/sec的值，如果出現高頻率的編譯，那麼就適合進行引數化改造。其次就是對CPU使用率的監控，如果CPU平均利用率都很高，那麼也可能需要考慮。
如果決定了進行引數化改造，可以使用下面語句查詢相同的query hash值但有不同的cache的語句。但是在結果集裡面，對於2、3次的那種可以先不考慮，應該著重關注那些非常高的（本人見過上千的），這型別就可以作為優先引數化的候選語句。
SELECT dest.text, deqs.query_hash, count (*) query_count FROM sys.dm_exec_query_stats deqs CROSS APPLY sys.dm_exec_sql_text(deqs.sql_handle) AS dest GROUP BY (query_hash), dest.text ORDER BY query_count DESC GO
前面的方式對於2016之前的版本（最晚從2012開始，2008R2沒研究），但是如果使用了SQL 2016及後續版本，有一個新功能來更好地處理這個問題，就是Query Store，具體使用後續再講解。
最後針對引數化的問題，引數化最好的實現方式還是在前端應用程式，但是如果沒法修改前端程式（如購買的軟體），那麼修改資料也不失為方案之一。但是再次提醒：只要不是預設值，那就要考慮適用場景！比如這個選項可能會降低查詢的編譯導致某些本身應該編譯的語句沒有得到編譯，從而獲取非最優的執行計劃，最終影響效能。
READ_COMMITTED_SNAPSHOT
在本人經歷裡面，90%以上的效能問題都源自於阻塞，不過阻塞的根源卻是多種多樣的。如果出現了併發問題導致阻塞，那麼可以嘗試修改相容級別。在修改之前可以先看看官方文件： 事務鎖定和行版本控制指南 。很多時候，正是由於讀寫互相阻塞導致了會話阻塞的出現。把READ_COMMITTED_SNAPSHOT開啟可以使得讀操作移到快照中進行，快照內是已提交的資料，這樣寫操作就可以減少被阻塞的機率，不過這種實際上是把讀負載移到TempDB中，所以TempDB更加需要合理配置和使用。除了讀提交快照之外，還可以使用單純的快照和行版本來減少這類阻塞，具體內容可以參閱官方文件： 瞭解快照隔離和行版本控制
SCOPED CONFIGURATION
這是從SQL Server 2016引入的新配置。在過去只能通過例項層面的配置或者使用跟蹤標記來實現。比如前面提到的例項層面的max degree of parallelism，現在可以使用ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP=某個值來覆蓋資料庫層面的值。
另外還有一個可能要用到的就是 QUERY_OPTIMIZER_HOTFIXES，這個等於跟蹤標記4199。用於啟用查詢優化器的hotfixes，但是這裡僅僅是對語句級別，這樣可以減少全域性影響，更加細粒度和智慧。完整的內容可以參看官方文件： ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL)
這一篇簡單介紹了在資料庫層面針對性能的配置項，從SQL 2012開始，庫和例項的關係已經不再那麼緊密，所以在後續的版本中，不僅要對例項進行配置，也要對資料庫進行配置。