本人新書上市，請多多關照：《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開始，庫和實例的關係已經不再那麼緊密，所以在後續的版本中，不僅要對實例進行配置，也要對數據庫進行配置。