用扩展事件搞定SQL Server那些复杂又难缠的故障排查问题

（引用来源：SQL Server资深工程师的实践经验分享、微软官方文档关于扩展事件的概述、以及技术社区如SQLServerCentral中的相关案例讨论）

说到SQL Server的故障排查，很多搞数据库的朋友可能第一时间会想到SQL Trace和SQL Server Profiler这个老工具，确实，它曾经是主力军，但微软自己都说了，这玩意儿未来是要被淘汰的，而且它开销大，对服务器性能影响不小，有点像开着拖拉机上高速去追查一辆跑车的问题，车没追上,自己先把路给堵了。

那用什么来代替它呢？就是今天要说的主角——扩展事件，你可以把它想象成SQL Server内置的一个超级精密、高度可定制的“监控摄像头系统”或者“黑匣子”，它的核心优势就是开销极低，低到几乎可以忽略不计，这意味着你甚至可以把它在生产环境上长期开着，持续捕捉问题,而不用担心把服务器拖垮。

那这个“黑匣子”具体怎么帮我们搞定那些复杂又难缠的故障呢？咱们不看那些让人头晕的专业术语,就举几个实实在在的例子。

追查那个“偶尔抽风”的慢查询

这是最经典的场景，用户抱怨说系统时不时就卡一下，但又不是一直卡，你用常规方法去查，可能那个慢查询早就跑完了,死无对证。

用扩展事件来搞，就很简单，你不需要像以前用Profiler那样抓取海量的数据，你只需要精准地告诉扩展事件：“你给我盯紧喽，只要有任何一个SQL语句执行时间超过5秒钟，你就把当时的关键信息给我记录下来。” 你设置的事件就是“sql_statement_completed”，然后加一个条件“duration > 5000000”（单位是微秒），你还可以让它一并记录下执行计划、是哪个用户执行的、从哪台机器连过来的等等。

这样一来，你就不用在大海捞针了，扩展事件会像忠诚的卫兵，一旦有超时的“嫌疑犯”出现，立刻拍下照片（记录事件），等你来查，你拿到这些记录，就能清晰地看到到底是哪条SQL语句慢，当时它生成的执行计划是什么样的，是不是因为缺少索引或者统计信息过期了,问题根源一目了然。

揪出那个“神出鬼没”的阻塞源头

阻塞问题更让人头疼，因为它往往是瞬时的，等你收到报警远程登录上去，阻塞可能已经解除了,只剩下风中凌乱的你。

这时候，扩展事件的“因果跟踪”能力就派上大用场了，你可以创建一个事件会话，同时抓取两个关键事件：一个是“lock_acquired”（获取锁），另一个是“lock_timeout”或“lock_deadlock”（锁超时或死锁），最关键的一步是，你要启用这个事件会话的“因果关系跟踪”功能，这个功能会为每个相关的活动分配一个唯一的ID，这样你就能像看侦探小说的线索图一样，清晰地看到：是哪个会话（A）先持有了锁，然后哪个会话（B）又在等待这个锁,它们各自在执行什么语句。

当再次发生阻塞或死锁时，扩展事件记录下来的就不是一堆孤立的事件了，而是一张完整的“犯罪现场关系图”，你直接就能定位到罪魁祸首是哪个会话、哪条语句,再也不用像以前那样去猜去看一堆复杂的系统视图了。

诊断那些“莫名其妙”的错误和异常

应用会报一些奇怪的错误，比如连接失败、权限问题、或者某些操作意外终止，这些错误日志可能分散在SQL Server错误日志和Windows事件查看器里,拼凑起来很麻烦。

扩展事件提供了一个叫“error_reported”的事件，它可以捕捉到SQL Server内部产生的几乎所有错误，你可以通过设置筛选条件，只关注错误严重度比较高的（比如大于等于16），或者只关注特定的错误号，当错误发生时，它不仅能记录错误信息，还能捕获当时的调用堆栈、会话上下文等深度信息。

这对于诊断一些间歇性的、由底层代码或环境引发的诡异问题非常有帮助，相当于给SQL Server装了一个高灵敏度的“错误监听器”,任何风吹草动都逃不过它的耳朵。

怎么上手操作？

虽然扩展事件功能强大，但一开始可能会觉得有点复杂，SQL Server Management Studio (SSMS) 提供了图形化界面来创建和管理扩展事件会话，这大大降低了门槛，你基本就是在界面上勾勾选选：先给会话起个名字，然后从一大堆事件列表里挑出你关心的（比如上面提到的那些），接着设置筛选条件（比如只盯超过5秒的查询），最后选择记录数据的方式（可以实时显示在屏幕上，也可以保存到文件里方便以后分析）。

扩展事件就像是送给SQL Server DBA的一把瑞士军刀，它小巧、精准、有力，告别Profiler那种“粗放式”的监控，转向扩展事件的“精准打击”，是搞定SQL Server复杂故障排查的必经之路，只要你花点时间熟悉几个常用的事件和动作，就会发现排查问题的效率得到了质的飞跃,以前那些难缠的故障也不再那么令人畏惧了。

（引用来源结束）