sqlserver在线测试

上周帮一个朋友排查生产环境的测试死锁问题，他发来一段SQL，测试我复制到SSMS里执行，测试等了快两分钟才出结果。测试他那边服务器配置不差，测试问题出在语句本身——一个没走索引的测试嵌套查询。这事让我又想起一个老话题：手边没有SQL Server环境时，测试怎么快速验证语句的测试正确性和性能表现。在线测试工具就是测试干这个的。

目前能用的测试SQL Server在线测试平台不算多，质量也参差不齐。测试我试过七八个，测试db<>fiddle 是测试其中比较稳的一个。它支持SQL Server 2014到2022多个版本，测试打开网页直接写T-SQL，测试点Run就能看到结果集和执行计划。对于临时验证语法、测试函数行为、复现一个锁等待场景，足够用了。另一个是SQL Fiddle，界面老派，但胜在轻量，适合快速贴一段建表语句加查询。不过它默认的版本偏旧，用STRING_AGG或者OFFSET FETCH这类较新的语法时得手动切换。

在线工具最大的局限在数据量。你没法往里面塞几百万行数据去测索引效果。我通常的做法是构造几十行代表性数据，配合SET STATISTICS IO ON来观察逻辑读的次数。有一次我对比WHERE EXISTS和IN在子查询里的表现，用在线环境跑小数据集，两者执行计划几乎一样。但换到本地一台装了两百万行测试表的实例上，差异立刻出来了——优化器对半连接和半反连接的估算方式不同，导致一个走哈希匹配、一个走嵌套循环。在线测试能帮你排除语法错误和逻辑错误，性能结论别太当真。

写T-SQL时有些坑在线环境反而更容易暴露。比如字符串拼接时NULL的处理，SELECT 'a' + NULL返回NULL，而CONCAT函数会忽略NULL。这种细节在文档里读过就忘，亲手在在线编辑器里跑一遍，报错或者空结果直接拍脸上，记忆深得多。还有日期格式转换，SET DATEFORMAT不同设置下'01/02/2023'可能解析成一月二日或二月一日，在线环境可以随意切换语言和格式设置，比在正式服务器上折腾安全。

临时表的使用也值得在线练手。全局临时表##temp在会话间共享，本地临时表#temp随会话销毁。在线工具通常每个查询窗口是一个独立会话，你可以开两个标签页模拟并发访问，观察一个会话插入数据后另一个会话能否看到。这种实验在本地做要开两个SSMS连接，在线点两下鼠标就行。不过要注意，有些平台为了隔离，会把每个查询放到独立数据库或独立实例，全局临时表的行为可能和真实环境有出入。

执行计划的可视化是在线工具另一个实用点。db<>fiddle能显示图形化计划，虽然缩放和拖拽体验比不上SSMS，但看个大概的运算符流向够了。我经常用它来确认某个查询是否发生了隐式转换——在图形计划里看到黄色感叹号的警告图标，就知道该检查列类型和参数类型是否匹配了。这种问题在代码审查时很难用肉眼发现，跑一下计划一目了然。

要说缺点，在线环境没法测SQL Server Agent作业、链接服务器、CLR集成这些偏运维和扩展的功能。文件组、分区方案、Always On可用性组更不用想。它就是一个T-SQL沙盒，适合验证语言层面的东西。我自己的习惯是：写复杂查询前先在在线工具里把逻辑跑通，确认结果集正确，再拿到本地或测试服务器上做性能调优。两段式流程，省得在正式环境里反复改语句、反复执行、反复等结果。

最后提一句安全。别把生产环境的真实数据贴到任何在线测试平台。表名、列名、甚至查询里的常量值都可能泄露业务信息。我见过有人把客户表结构和样本数据直接粘到公共fiddle里求助，那跟把数据库备份发到论坛上没区别。用虚构的表名和脱敏数据，这个习惯得养成。