不少时候有这样的场景,开发抱怨DBA没有调优好数据库,DBA抱怨开发写的程序代码差,所以,DBA和开发都成为了死对头,没法真正排查问题。sql
DBA只能使用Windows性能监视器,SQL Server内置的活动监视器、SQL Trace、SQL Profiler、Performance Dashboard等工具,或者使用执行计划来查看查询成本。数据库
为了让DBA有更多有效工具排查问题,SQL Server2016推出了不少新功能,其中一项功能是 Live Query Statistics(LQS 实时查询统计信息),这个功能显示了以往不容易看到的执行时期的内容,例如查询期间的统计信息,这个功能能够帮助DBA找出长时间查询的真正问题根源(root cause)工具
使用实时统计查询性能
使用实时查询统计很是简单,只须要在SSMS的工具列,分别按一下【包括实际的执行计划】【包括实时查询统计信息】图标,并执行您的查询就能够了。优化
如今能够在【实时查询统计信息】tab页看到查询所用到的运算符,正在统计查询耗费时间,另外在tab页面的左上角能够看到整个查询的完成度spa
使用【实时查询统计信息】会对性能有必定影响,当查询比较复杂的时候,所需等待时间也会增长,而且整个过程也会耗用很多CPU资源,所以使用的时机必需要审慎,不然问题未查出来,反而形成数据库更大的压力。code
提示
若是只使用了【包括实时查询统计信息】,而未打开【包括实际执行计划】,那么在【包括实时查询统计信息】的tab页所看到的通过时间和完成率都会是0orm
不会显示消耗时间blog
在执行计划中向下钻取(drill down)索引
在实时查询统计信息执行过程当中,能够点击任何一个执行计划中的运算符,查看运算符的统计信息,例如:消耗时间(Elapsed time)、运算符的处理进度(operator progress)、目前CPU使用率,根据这些信息帮助DBA找出瓶颈所在
另外,当查询依然在执行时能够切换到活动监视器,在新增长的【活动的耗费大量资源的查询】tab页里能看到当前正在活动的耗时查询,直到该查询执行完毕
实时查询统计信息原理
实时查询统计信息背后的原理实际上是经过DMV动态管理视图获取信息,而后呈如今tab页面上,从而让DBA能够不须要自行查询这些DMV,直接以图形化界面来快速找到长时间执行的查询是在哪一个环节耗费最多时间和成本。
下面是实时查询统计信息所使用的DMV,固然本身也能够经过下面的DMV来查询得到须要的统计信息
SELECT * FROM sys.dm_exec_requests SELECT * FROM sys.dm_exec_sql_text SELECT * FROM sys.dm_exec_query_memory_grants SELECT * FROM sys.dm_exec_query_plan SELECT * FROM sys.dm_exec_query_profiles
限制
目前实时查询统计信息尚不支持下列功能
列存储索引(columnstore indexes)
内存优化表(memory optimized tables)
本地编译存储过程(Natively compiled stored procedures)
功能截图
更多SQL Server2016好用功能敬请期待o(∩_∩)o