SQL Server 遭受大并发量时，该做些什么

些什么"/>

SQL Server 遭受大并发量时，该做些什么

前言  

L，大面积用户登录不了，咋回事啊

啊，不会吧，我看看啊

只要是 IT 职场老鸟，上述系统大面积报停的场面肯定再熟悉不过了。负责人不管是项目经理还是产品经理，轻描淡写的一句“咋回事儿啊”，轻则吓得你面红耳赤，冲则口吐鲜血，不省人事。别以为这是笑话，某银行 Oracle 宕机后，DBA 赶到现场敲开 sql*plus，鼓捣一阵后 直接吐血昏倒。这是血的教训。如果你没遇到，恭喜你，你还年轻。

这类问题，平时没有做过基准线测试的朋友肯定会慌。问问自己，设计的系统能承受多少的并发请求，（讲人话）当 2000 个用户同时登陆系统，查看自己有没有新的消息，页面能在多少时间返回？那么当有 20 万，200 万用户呢。你设计的系统能保证多少人同时访问，并在 1s 内返回请求的数据？

这些问题就是基准线，不知道各位在设计系统的时候，做了测试么？

正文

上面所说，是设计所考虑的主动规划，而现实中往往迫于产品经理或项目经理的淫威，开发人员特别是 SQL 开发人员绝对没有时间来做的事情。上线之后只能烧香拜佛，祈祷千万别来个 10W+ 访问。而现实却会啪啪打脸，所谓越怕的事情越容易发生。作为专业背锅侠，SQL 开发绝对冲在第一线。前端 UI 的异常，报出来的全是数据库连接超时，你说老板不找 SQL 开发难道去找 UI 写 JS 的？

作为补救措施，在昧着自己良心上线未经压力测试的数据应用系统之后，应当做好每日的巡检工作。而其中最重要的一项便是响应统计分析。不知道系统每日访问量，访问峰谷值，QPS, UPS, 我觉得就和拿着 AK47 直往前冲，全然不顾敌人多少，子弹多少一样，自寻死路。

 SQL Server 中有一张神奇的性能表，应用好此表，即可提早知晓 80% 的性能问题:

sys.dm_os_performance_counters.

记载了与 perfmon 中 SQLServer 指标下相同的性能计数器。通过这些计数器可以得到数据库在某段时间内的性能变化。perfmon 可以监控当下最新的系统状态，而对 sys.dm_os_performance_counters 做持续性跟踪记录，便能监控更长时间数据库性能的状态。

主角

性能指标有很多个，每个都要关注未免有点力不从心。聪明的开发者一般都有自己用得顺手的指标。今天介绍一个我喜欢用的 Batch Resp Statistics. 当然你肯定有自己喜欢的，欢迎来文讨论。

Batch Resp Statistics, 用来记录响应统计值。这些值都是自 SQL Server 启动以来累加的统计值。举个例子，一个请求耗时 2ms, 假设系统自启动以来有 2000万个这样的请求，那么总计 4000万 ms 便是计数器 （Elapsed Time:Total(ms) ）的值。

对 Elapsed Time:Total(ms) 做间隔时间的跟踪，比如 5s. 可以得到这 5s 内是否出现访问量剧烈跳动的异常，假设做成折线，斜率是非常陡峭的：

在稳定的访问时间段，增长都是温和的，基本维持在一个小斜率的曲线上。访问放量之后，斜率就几近垂直了。此刻就要在日志系统分析，是否有异常。这基本属于另一个话题，比如增长，黑客攻击等。数据分析的魅力就在于此，脑洞特别大就越有趣。

配合下面的净增增长柱状图，能在更细粒度查看系统承载的访问量。细看之下，46s 的时候，尽然有 250000 次请求。之后请求又回落到正常的区间。这足以让每个 SQL 开发或 DBA 紧张起来。

在跟踪 Batch Resp Statistics 时，需分清指标维度和指标性质。指标维度是区分请求与批次（Batch）的个体，一个批次中会有多个请求；指标性质区分时间分段，仅仅 CPU 耗时，还是整体耗时。

精彩内容

本号精华合集

关于作者

推荐朋友 Iyven 的公众号【SQL数据库开发】。同道中人，都是 SQL 爱好者。作者文章思路清晰，知识框架全面，系统性学习 SQL 的好地方。此号有太多特色：想要视频，这里有；想要电子书，这里都给您备齐了；想要经典的 SQL 编程题，关注吧，取之不尽。