【走进RDS】之 SQL Server 性能诊断案例分析

客户的困扰

前几天某程序员小王向阿里云咨询他的SQL Server数据库整体负载较高，是否有优化的方法？前几天另外一个工单则是需要阿里云工程师帮忙定位某一个时刻的数据库性能尖刺的问题。

这些都是常见的性能诊断工单，其实数据库性能诊断不仅对其数据库技能要求较高，而且需要大量的前期准备工作，如收集各种性能基线、性能指标和慢SQL日志等，尤其是面对多数据库性能调优时，往往事倍功半。

如何评估数据库负载情况？如何评估数据库

当问到，如何评估数据库负载时，不同角色可能想到不同的方法，例如以下几种：

• QPS/TPS
• 资源使用: IOPS CPU 内存
• SQL执行时间
• 并发量
• Application业务反馈

上述每一种评价方法都较为片面且作为对实际调优的参考也较为困难。

通常情况下，我们评价数据库资源负载是一个较为复杂的事情，需要我们对关系数据库有一个较为全面的理解才行，但作为数据库的使用者，大多数人不需要对数据库进行深入学习，因此，我们倾向于简化指标。

比如说，我们会只看CPU、IO、内存等指标看数据库是否存在问题，这些指标适用于监控大多数应用，但对于数据库来说可能并不能够较为正确的反映数据库内发生了什么，以及我们该如何处理。我们还要结合很多数据库特有的指标综合判断，比如各种SQL Server专用的性能计数器、DMV、等待类型、长事务、网络、活动连接等等。但这些信息需要我们对数据库自身有一个高级的了解，这使得评估数据库的负载成为一个较高门槛的工作。

下面我们不妨换一个思路，关系数据库本身是一个同步调用的过程，也就是说，从应用程序发起SQL，到数据库返回结果，是同步的，数据库不完成该请求，那么应用程序无法收到结果，在此期间应用程序与数据库之间的Session就是所谓的“Active”状态，因此我们可以尝试不再从资源使用的角度出发评估数据库负载，而简化为一个简单的指标-AAS（Average Active Session），也就是活跃会话数量。

什么是AAS概念？

设想一下，当你开车去一个目的地时，你更关注的是什么？目的地的距离？路