★ FEATURED ARTICLE 简介本资源是专为SQL Server数据库工程师、DBA及求职者打造的高频面试题精编集覆盖数据库原理、T-SQL实战与高阶运维三大维度直击技术面试核心考点。内容系统梳理23个基础知识要点如主键/外键本质、索引类型与最左前缀原则、16道笔试基础题含子查询、多表更新、空值处理等典型SQL写法及10余道高级篇真题涉及内存泄漏、TempDB异常、索引失效诊断、SQL注入防御等生产级问题每题均附清晰解析与最佳实践建议。资源以单个PDF文件形式交付776KB排版规范、重点突出便于离线查阅与碎片化复习。目前已有2838人学习下载是备考SQL Server岗位、夯实数据库内功与快速查漏补缺的高性价比参考资料。1. SQL Server 高频面试题及答案不是背题库是拆解真实生产环境里的“临场反应点”你有没有遇到过这样的面试现场刚答完“什么是事务隔离级别”面试官立刻追问“那在你们线上订单库READ COMMITTED SNAPSHOT 是开还是关为什么没用 SNAPSHOT锁升级触发条件改过吗”——这时候光背定义就露馅了。这份《SQL Server 高频面试题及答案》不是教科书式罗列而是从某公司 DBA 团队近三年的 276 场技术面谈中反向提炼出的 43 个真问题覆盖执行计划解读、死锁日志分析、备份链断裂恢复、内存压力下 tempdb 争用排查等 8 类高频实战场景。它不教你“标准答案”而是展示每个问题背后的真实约束比如“如何优化一个跑 47 分钟的报表查询”答案里会明确写出“该库未启用查询存储统计信息更新策略为 AUTO但主表有 2.3 亿行且存在大量空值分布偏斜”。适合两类人一是准备跳槽的中级 DBA 或后端工程师需要把“会写 SQL”升级成“能说清 SQL 在 SQL Server 里怎么活”二是带团队的技术负责人用它快速校准新人对 SQL Server 底层行为的理解水位。2. 执行计划与性能瓶颈定位从 XML 计划树到关键算子血缘追踪2.1 如何从 SSMS 图形化执行计划里一眼识别“伪并行”陷阱SQL Server 的图形化执行计划看似友好但极易掩盖真实瓶颈。常见误区是看到“并行度8”就认为 CPU 充足却忽略Parallelism (Gather Streams)算子下方的Clustered Index Scan是否出现Actual Rows远大于Estimated Rows如预估 1.2 万实际扫描 890 万。这种偏差往往源于统计信息陈旧或直方图桶溢出。验证方法不是看顶部“总耗时”而是右键点击扫描算子 → “属性” → 拉到底部查看Actual Number of Rows与Estimated Number of Rows的比值。若比值 5且该表近 7 天无UPDATE STATISTICS WITH FULLSCAN则优先怀疑统计信息失效。-- 快速检查指定表的统计信息最后更新时间与行数偏差 SELECT t.name AS table_name, s.name AS stats_name, s.auto_created, s.user_created, s.no_recompute, sp.last_updated, sp.rows, sp.rows_sampled, CAST(sp.rows_sampled AS FLOAT) * 100 / NULLIF(sp.rows, 0) AS sample_percent, sp.unfiltered_rows FROM sys.tables t JOIN sys.stats s ON t.object_id s.object_id CROSS APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) sp WHERE t.name Orders -- 替换为目标表名 ORDER BY sp.last_updated DESC;提示sp.unfiltered_rows是 SQL Server 2016 新增字段反映统计信息采样时未被过滤的原始行数比rows更能反映数据膨胀程度。若unfiltered_rows比rows高出 3 倍以上说明大量 INSERT/DELETE 未触发自动更新。2.2 解析 XML 执行计划中的隐藏线索WaitStats与QueryTimeStats图形化界面不显示等待类型和 CPU/Elapsed 时间拆分而这恰恰是区分“真慢”和“假慢”的关键。导出 XML 计划后搜索QueryTimeStats节点可获取ElapsedTimeMs和CpuTimeMs搜索WaitStats则能看到各阶段等待明细。例如某查询ElapsedTimeMs12400,CpuTimeMs890但WaitStats中PAGEIOLATCH_SH占 11200ms —— 这直接指向磁盘 I/O 瓶颈而非 SQL 写法问题。此时应检查sys.dm_io_virtual_file_stats中对应数据库文件的io_stall_read_ms是否持续高于 50ms。-- 定位高 I/O 延迟的数据文件单位毫秒 SELECT DB_NAME(vfs.database_id) AS db_name, mf.name AS logical_name, mf.physical_name, vfs.io_stall_read_ms, vfs.io_stall_write_ms, vfs.io_stall_read_ms vfs.io_stall_write_ms AS io_stall_total_ms, vfs.num_of_reads, vfs.num_of_writes FROM sys.dm_io_virtual_file_stats(NULL, NULL) vfs JOIN sys.master_files mf ON vfs.database_id mf.database_id AND vfs.file_id mf.file_id WHERE vfs.io_stall_read_ms vfs.io_stall_write_ms 10000 ORDER BY io_stall_total_ms DESC;注意io_stall_read_ms高不一定代表磁盘坏也可能是内存不足导致 Buffer Pool 频繁刷脏页。需同步检查sys.dm_os_performance_counters中Page life expectancy是否低于 300 秒。2.3 关键算子行为解码Key Lookup与RID Lookup的成本差异当执行计划中出现Key Lookup聚集索引查找或RID Lookup堆表查找其成本常被低估。Key Lookup需要先通过非聚集索引找到聚集索引键再回表查完整行而RID Lookup直接通过行标识符定位理论上更快。但实际中Key Lookup更常见因其依赖聚集索引结构稳定。若Key Lookup的Actual Number of Rows达到百万级即使单次成本仅 0.0001ms总成本也超 100ms。优化方向不是消灭 Lookup而是评估是否值得添加INCLUDE列。例如查询SELECT OrderID, CustomerID, OrderDate FROM Orders WHERE Status Shipped若Status上有非聚集索引但未包含OrderDate则必然触发Key Lookup。此时应重建索引-- 将原有索引改造为覆盖索引 DROP INDEX IX_Orders_Status ON Orders; CREATE NONCLUSTERED INDEX IX_Orders_Status_Incl ON Orders (Status) INCLUDE (OrderDate, CustomerID); -- 显式包含 SELECT 中所有非 WHERE 字段提示INCLUDE列不参与索引排序不增加 B-Tree 层级但会增大索引体积。需权衡SELECT频率与INSERT/UPDATE频率。某电商系统实测对日均 50 万订单表添加 3 个INCLUDE字段使索引体积增 12%但该查询平均耗时从 840ms 降至 47ms。3. 事务与锁机制深度解析从隔离级别到死锁图逆向还原3.1 READ COMMITTED SNAPSHOT 的启用代价与监控盲区READ COMMITTED SNAPSHOTRCSI是解决读写阻塞的常用方案但启用后并非一劳永逸。其核心代价是tempdb的version store空间激增。当事务长时间运行如未提交的BEGIN TRAN持续 2 小时所有被修改行的旧版本必须保留在tempdb中直到该事务结束。这会导致tempdb文件自动增长失控。监控不能只看tempdb总大小而要查sys.dm_tran_version_store_space_usage-- 检查 version store 空间占用SQL Server 2019 SELECT database_id, reserved_page_count, reserved_space_kb, max_version_chain_traversed, average_version_chain_length FROM sys.dm_tran_version_store_space_usage;注意max_version_chain_traversed 100表示某行版本链过长可能因长事务或高并发 UPDATE 同一行导致。此时应结合sys.dm_exec_sessions查找transaction_isolation_level 6SNAPSHOT且open_transaction_count 0的会话。3.2 死锁图Deadlock Graph的手动解析三步法SQL Server 生成的.xdl死锁图是 XML 格式但多数人只看图形界面中的“获胜进程”和“牺牲进程”。真正价值在于process-list中的executionStack和resource-list中的owner-list/waiter-list。解析步骤定位资源冲突点在resource-list中找objectnamedbo.Orders且modeX排他锁与modeU更新锁同时存在的节点追溯持有者 SQL在process-list中找到idprocess123对应的executionStack提取最内层frame的procname和line确认等待链闭环检查process123的waitresource是否等于process456的owner-id且process456的waitresource又指向process123—— 这才是死锁铁证。常见误判将LCK_M_U等待误认为死锁实则是单向阻塞。死锁必有双向等待环。3.3 锁升级Lock Escalation的隐性触发条件与规避策略锁升级阈值默认为 5000 行但实际触发受两个隐藏条件制约内存压力触发当 SQL Server 内存不足时lock_escalation可能提前至 2500 行分区表特殊规则若表已分区锁升级按分区粒度计算即单个分区达 5000 行即升级为TAB锁。规避方法不是盲目调高阈值ALTER TABLE ... SET (LOCK_ESCALATION DISABLE)有严重风险而是对高频更新的大表按业务逻辑拆分为多个小表如Orders_2023Q1,Orders_2023Q2在 UPDATE 语句中显式使用ROWLOCK提示需确保 WHERE 条件能走索引否则提示被忽略对批量操作分批次提交每 1000 行COMMIT一次避免单事务锁行数超标。-- 安全的分批更新模板避免锁升级 DECLARE BatchSize INT 1000; DECLARE RowsAffected INT 1; WHILE RowsAffected 0 BEGIN BEGIN TRAN; UPDATE TOP (BatchSize) o SET Status Processed FROM Orders o INNER JOIN OrderDetails od ON o.OrderID od.OrderID WHERE o.Status Pending AND od.LastUpdated DATEADD(HOUR, -2, GETDATE()); SET RowsAffected ROWCOUNT; COMMIT TRAN; -- 强制短暂休眠降低锁竞争 WAITFOR DELAY 00:00:00.010; END提示WAITFOR DELAY不是银弹但在高并发场景下10ms 休眠可使锁冲突率下降 37%某支付系统压测数据。关键是要让其他会话有机会获取锁。4. 备份恢复与高可用架构从 FULL 备份链断裂到 AG 同步延迟诊断4.1 FULL 备份链断裂的 3 种典型场景与应急恢复路径备份链断裂不等于数据丢失。常见断裂点日志截断失败BACKUP LOG未执行且log_reuse_wait_desc LOG_BACKUP此时DBCC OPENTRAN显示活动事务但CHECKPOINT无法推进min_active_log复制延迟发布服务器上sys.dm_repl_traninfo显示last_commit_time滞后 2 小时导致日志无法截断AlwaysOn AG 主副本切换新主副本未及时配置backup_priority导致日志备份作业在旧主上运行失败新主日志持续增长。应急恢复步骤立即在主副本执行BACKUP LOG [DBName] TO DISK NUL仅 SQL Server 2012 支持强制截断日志检查sys.database_mirroring或sys.dm_hadr_database_replica_states确认 AG 同步状态若日志文件已满使用DBCC SHRINKFILE (NYourLogName, 1)收缩至 1MB仅限紧急情况收缩后立即做完整备份。4.2 AlwaysOn 可用性组同步延迟的根因分级排查AG 延迟不是简单看redo_queue_size需分三层定位层级检查指标正常阈值根因示例网络层sys.dm_hadr_database_replica_states.log_send_queue_size 10MB主副本网卡丢包率 0.1%或防火墙限制 5022 端口日志传输层log_send_rateKB/sec 5000 KB/sec主副本tempdb空间不足日志压缩线程阻塞重做层redo_rateKB/sec 3000 KB/sec辅助副本MAXDOP设置过高重做线程争用 CPU-- 一键诊断 AG 延迟主副本执行 SELECT ar.replica_server_name, drs.database_name, drs.synchronization_state_desc, drs.synchronization_health_desc, drs.log_send_queue_size / 1024.0 AS log_send_queue_MB, drs.redo_queue_size / 1024.0 AS redo_queue_MB, drs.log_send_rate / 1024.0 AS log_send_rate_MBps, drs.redo_rate / 1024.0 AS redo_rate_MBps, DATEDIFF(SECOND, drs.last_commit_time, GETDATE()) AS commit_delay_sec FROM sys.dm_hadr_database_replica_states drs JOIN sys.availability_replicas ar ON drs.replica_id ar.replica_id WHERE drs.database_name YourDB;提示commit_delay_sec 30 秒时优先检查辅助副本sys.dm_os_schedulers中current_tasks_count是否持续 100表明重做线程积压。4.3 日志传送Log Shipping的“静默失败”陷阱与心跳检测日志传送失败常无声无息备份作业成功复制作业成功但还原作业因权限或路径错误失败msdb.dbo.log_shipping_monitor_alert却未告警。根本原因是alert_threshold默认为 4320 分钟3 天远超业务容忍窗口。必须手动增强监控在还原作业末尾添加 T-SQL 步骤检查msdb.dbo.log_shipping_secondary_databases.last_restored_date是否滞后超过 15 分钟创建 SQL Agent 警报监听Error Number 14421日志传送还原失败每 5 分钟执行一次心跳查询验证SELECT TOP 1 * FROM YourTable ORDER BY LastModified DESC的LastModified是否在 10 分钟内更新。-- 日志传送心跳检测脚本辅助服务器执行 DECLARE MaxDelayMinutes INT 10; DECLARE LastUpdate DATETIME; SELECT LastUpdate MAX(LastModified) FROM YourDB.dbo.YourTable; IF DATEDIFF(MINUTE, LastUpdate, GETDATE()) MaxDelayMinutes BEGIN RAISERROR(Log shipping heartbeat failed: last update %d minutes ago, 16, 1, DATEDIFF(MINUTE, LastUpdate, GETDATE())); END注意此脚本需部署为独立作业不可与还原作业绑定。否则还原失败时心跳作业也失败失去监控意义。5. 避坑指南SQL Server 面试中 5 个高频翻车点与血泪解决方案5.1 现象回答“如何查看阻塞链”时只说sp_who2被追问“sp_who2为什么看不到跨实例阻塞”原因sp_who2是系统存储过程仅返回当前实例的会话信息且已标记为“向后兼容”官方文档明确建议改用sys.dm_exec_requests和sys.dm_exec_sessions。更致命的是它无法关联blocking_session_id的源头如该阻塞者本身被另一个会话阻塞。解决必须掌握递归 CTE 查询阻塞链-- 递归查询完整阻塞链支持多层嵌套 WITH BlockingChain AS ( -- 锚点找出最顶层的阻塞者不被任何人阻塞 SELECT r.session_id, r.blocking_session_id, s.host_name, s.program_name, s.login_name, r.status, r.command, r.wait_type, r.wait_time, r.last_wait_type, r.cpu_time, r.total_elapsed_time, 0 AS level FROM sys.dm_exec_requests r JOIN sys.dm_exec_sessions s ON r.session_id s.session_id WHERE r.blocking_session_id 0 AND r.session_id 50 -- 排除系统会话 UNION ALL -- 递归查找被锚点阻塞的会话 SELECT r.session_id, r.blocking_session_id, s.host_name, s.program_name, s.login_name, r.status, r.command, r.wait_type, r.wait_time, r.last_wait_type, r.cpu_time, r.total_elapsed_time, bc.level 1 FROM sys.dm_exec_requests r JOIN sys.dm_exec_sessions s ON r.session_id s.session_id JOIN BlockingChain bc ON r.blocking_session_id bc.session_id ) SELECT REPLICATE(→, level) CAST(session_id AS VARCHAR(10)) AS chain, host_name, program_name, login_name, status, command, wait_type, wait_time, total_elapsed_time FROM BlockingChain ORDER BY level, session_id;提示面试时若被问“为什么不用sys.dm_os_waiting_tasks”应回答“waiting_tasks只显示当前等待的会话不包含已执行完成的阻塞历史而dm_exec_requests实时反映请求状态配合递归 CTE 可构建完整因果链。”5.2 现象解释“索引碎片”时混淆avg_fragmentation_in_percent与avg_page_space_used_in_percent原因前者衡量页间逻辑碎片数据页物理顺序 vs 逻辑顺序偏差后者衡量页内空间利用率。面试官常故意混淆二者例如问“碎片率 30% 是否需要重建索引”若只看avg_fragmentation_in_percent而忽略page_count 1000则给出错误结论。解决必须结合三个指标决策page_count 1000小表碎片影响微乎其微avg_fragmentation_in_percent 30%重建索引REBUILDavg_fragmentation_in_percent BETWEEN 5% AND 30%重组索引REORGANIZEavg_page_space_used_in_percent 60%即使碎片低也需REORGANIZE以填充页空间。-- 生产环境索引维护决策脚本自动判断 REBUILD/REORGANIZE SELECT OBJECT_NAME(i.object_id) AS table_name, i.name AS index_name, ips.avg_fragmentation_in_percent, ips.page_count, ips.avg_page_space_used_in_percent, CASE WHEN ips.page_count 1000 THEN IGNORE: Small table WHEN ips.avg_fragmentation_in_percent 30 THEN REBUILD WHEN ips.avg_fragmentation_in_percent BETWEEN 5 AND 30 THEN REORGANIZE WHEN ips.avg_page_space_used_in_percent 60 THEN REORGANIZE (low page density) ELSE OK END AS recommendation FROM sys.indexes i CROSS APPLY sys.dm_db_index_physical_stats( DB_ID(), i.object_id, i.index_id, NULL, LIMITED ) ips WHERE i.type_desc IN (CLUSTERED, NONCLUSTERED) AND i.is_disabled 0 AND i.is_hypothetical 0;5.3 现象被问“如何迁移一个 5TB 数据库”时只答“用备份还原”忽略COPY_ONLY与日志链影响原因未考虑源库是否启用了FULL恢复模式。若直接BACKUP DATABASE会截断日志链导致后续日志备份失效。迁移大库必须用COPY_ONLY备份它不干扰现有日志序列号LSN链。解决迁移流程必须包含三要素源库执行BACKUP DATABASE [DB] TO DISK ... WITH COPY_ONLY, COMPRESSION目标库还原时使用WITH NORECOVERY为后续日志备份预留空间迁移窗口结束后对源库执行最后一次BACKUP LOG目标库用RESTORE LOG ... WITH RECOVERY完成切换。提示COPY_ONLY备份不能作为差异备份的基础但它是迁移场景的黄金标准。某金融系统曾因忘记COPY_ONLY导致交易日志备份链断裂被迫回退到 3 天前的完整备份。5.4 现象描述“参数嗅探”时只提OPTIMIZE FOR UNKNOWN不知QUERYTRACEON 4136的适用边界原因OPTIMIZE FOR UNKNOWN是查询级方案适用于单条语句而QUERYTRACEON 4136是全局跟踪标志禁用所有参数嗅探但会降低整体查询优化质量。面试官常追问“为何不用 4136”解决必须明确场景边界OPTIMIZE FOR ( param value )当参数值分布极不均匀且有明确“典型值”时OPTIMIZE FOR UNKNOWN当参数值随机性强无典型值且统计信息无法准确反映时QUERYTRACEON 4136仅用于临时诊断如DBCC TRACEON(4136, -1)绝不可长期启用因其强制所有参数化查询使用平均统计信息对高选择性谓词如WHERE ID id造成灾难性执行计划。-- 安全的参数嗅探缓解方案推荐 -- 方案1局部变量打断参数传递 DECLARE LocalStatus VARCHAR(20) InputStatus; SELECT * FROM Orders WHERE Status LocalStatus; -- 方案2查询提示SQL Server 2016 SELECT * FROM Orders WHERE Status InputStatus OPTION (OPTIMIZE FOR (InputStatus Shipped));5.5 现象回答“如何监控 CPU 瓶颈”时只说sys.dm_os_performance_counters漏掉sys.dm_exec_query_stats的total_worker_time原因Performance Counters中的% Processor Time是 Windows 层面指标无法定位到具体 SQL。而sys.dm_exec_query_stats的total_worker_time是 SQL Server 内核累计的 CPU 时间单位微秒可精确到单条查询。解决必须组合使用先用Performance Counters确认 SQL Server 进程sqlservr.exeCPU 占用是否持续 80%再用dm_exec_query_stats找出total_worker_time最高的 TOP 10 查询最后用sys.dm_exec_sql_text获取具体 SQL 文本并检查其执行计划是否存在Index Scan或Sort等高 CPU 算子。-- 定位高 CPU 消耗查询按总 worker time 排序 SELECT TOP 10 qs.execution_count, qs.total_worker_time / 1000000.0 AS total_cpu_sec, qs.total_worker_time / qs.execution_count / 1000000.0 AS avg_cpu_sec, qs.total_elapsed_time / 1000000.0 AS total_elapsed_sec, SUBSTRING(qt.text, (qs.statement_start_offset/2)1, ((CASE qs.statement_end_offset WHEN -1 THEN DATALENGTH(qt.text) ELSE qs.statement_end_offset END - qs.statement_start_offset)/2) 1) AS statement_text FROM sys.dm_exec_query_stats qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt ORDER BY qs.total_worker_time DESC;提示total_worker_time包含所有执行次数的 CPU 时间总和avg_cpu_sec才是单次平均。若某查询execution_count10000但avg_cpu_sec0.002说明它本身高效只是调用频繁若execution_count5但avg_cpu_sec12.5则必须优化该 SQL。6. 进阶技巧用 Extended Events 替代 Profiler 实现“零干扰”性能审计6.1 为什么 Profiler 在生产环境是定时炸弹SQL Server Profiler 是 GUI 工具其底层依赖sp_trace_create会强制 SQL Server 启动一个专用线程处理事件捕获该线程与用户查询线程竞争 CPU 和内存。某银行核心系统曾因开启 Profiler 捕获RPC:Completed事件导致CXPACKET等待飙升 400%TPS 下降 65%。而 Extended EventsXEvents采用轻量级异步事件管道事件消费由独立会话处理对主线程零侵入。关键区别在于Profiler 是“同步阻塞式”XEvents 是“异步缓冲式”。6.2 构建最小可行 XEvent 会话捕获慢查询与阻塞链以下会话仅捕获query_post_execution_showplan实际执行计划和xml_deadlock_report并设置 10MB 内存缓冲区完全规避磁盘 I/O-- 创建轻量级 XEvent 会话内存模式无磁盘写入 CREATE EVENT SESSION [Audit_SlowQueries] ON SERVER ADD EVENT sqlserver.query_post_execution_showplan( ACTION(sqlserver.client_app_name, sqlserver.client_hostname, sqlserver.database_name, sqlserver.sql_text) WHERE ([package0].[greater_than_uint64]([duration], (10000000))) -- 持续时间 10 秒 ), ADD EVENT sqlserver.xml_deadlock_report ADD TARGET package0.ring_buffer( SET max_memory (10240) -- 10MB 缓冲区 ); GO -- 启动会话 ALTER EVENT SESSION [Audit_SlowQueries] ON SERVER STATE START; GO提示duration单位是微秒10000000 10 秒。切勿设为0否则捕获所有查询内存瞬间爆满。6.3 从 ring_buffer 中提取并解析执行计划的 PowerShell 脚本XEvents 的ring_buffer输出是 XML需解析才能阅读。以下 PowerShell 脚本可自动提取、格式化并保存为.sqlplan文件供 SSMS 直接打开# PowerShell 脚本提取 XEvent ring_buffer 并生成 .sqlplan $serverInstance YourServer $sessionName Audit_SlowQueries # 查询 ring_buffer 内容 $query SELECT CAST(target_data AS XML) AS target_data FROM sys.dm_xe_session_targets xet JOIN sys.dm_xe_sessions xes ON xes.address xet.event_session_address WHERE xes.name $sessionName AND xet.target_name ring_buffer $xmlData Invoke-Sqlcmd -ServerInstance $serverInstance -Query $query # 解析 XML 并提取 execution plan $targetXml [xml]$xmlData.target_data $events $targetXml.EventFile.Target.RingBufferTarget.Event foreach ($event in $events) { if ($event.Name -eq query_post_execution_showplan) { $planXml $event.Data.Field | Where-Object { $_.Name -eq showplan_xml } | ForEach-Object { $_.Value } $fileName SlowQuery_ (Get-Date -Format yyyyMMdd_HHmmss) .sqlplan $planXml | Out-File -FilePath $fileName -Encoding UTF8 Write-Host Saved plan to $fileName } }注意此脚本需在安装了SqlServerPowerShell 模块的机器上运行且 SQL Server 登录账户需有VIEW SERVER STATE权限。6.4 XEvents 与 DMV 的协同审计框架建立“问题发现-定位-验证”闭环真正的生产审计不是单点抓取而是构建闭环发现用 XEvent 会话捕获异常事件如error_reported错误 823/824定位当 XEvent 触发时自动执行sp_WhoIsActive存储过程捕获当时所有会话快照验证将sp_WhoIsActive结果与 XEvent 中的sql_text关联确认错误是否由特定查询引发。-- 自动化审计存储过程简化版 CREATE PROCEDURE dbo.Audit_On_Error AS BEGIN -- 步骤1记录错误上下文 INSERT INTO AuditLog_ErrorContext (error_number, error_message, event_time) SELECT xed.value((event/timestamp)[1], datetime) AS event_time, xed.value((event/data[nameerror_number]/value)[1], int) AS error_number, xed.value((event/data[namemessage]/value)[1], nvarchar(max)) AS error_message FROM sys.fn_xe_file_target_read_file(Audit_Errors*.xel, NULL, NULL, NULL) AS f CROSS APPLY (SELECT CAST(event_data AS XML) AS xed) AS t; -- 步骤2捕获当前会话快照调用 sp_WhoIsActive IF OBJECT_ID(tempdb..#WhoIsActive) IS NOT NULL DROP TABLE #WhoIsActive; CREATE TABLE #WhoIsActive ( [dd hh:mm:ss.mss] varchar(15), [database_name] nvarchar(128), [login_name] nvarchar(128), [sql_text] xml, [status] varchar(30), [wait_info] nvarchar(4000), [CPU] int, [reads] bigint, [writes] bigint, [physical_reads] bigint ); INSERT INTO #WhoIsActive EXEC sp_WhoIsActive get_plans 1, get_outer_command 1, get_task_info 2; -- 步骤3关联错误与会话 INSERT INTO AuditLog_SessionLink (error_id, session_id, sql_text, cpu_time) SELECT e.id, w.session_id, w.sql_text, w.CPU FROM AuditLog_ErrorContext e CROSS JOIN #WhoIsActive w WHERE e.event_time DATEADD(SECOND, -30, GETDATE()) -- 关联最近30秒的会话 AND w.sql_text IS NOT NULL; END从那以后我每次上线新 XEvent 会话都强制走一遍sys.dm_xe_sessions状态检查、sys.dm_xe_session_targets缓冲区使用率监控、以及sys.fn_xe_file_target_read_file的首次读取验证——不是怕配置错而是怕它“静默失效”。因为生产环境里最危险的不是报错而是你以为它在工作其实早已停止呼吸。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
