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开始，库和实例的关系已经不再那么紧密，所以在后续的版本中，不仅要对实例进行配置，也要对数据库进行配置。