SQL Server中SQL CLR标量值函数随机触发空引用异常求助

看起来你遇到的问题核心是资源泄漏和未处理的null引用，结合SQL Server CLR的运行特性，才导致了前两次正常、第三次崩溃的奇怪现象。我来拆解一下原因和修复方案：

1. 资源泄漏导致连接池耗尽 #

你的代码里没有释放HttpWebRequest和HttpWebResponse这些实现IDisposable的对象。SQL Server的CLR AppDomain是复用的，前两次执行后，未释放的资源会占用HTTP连接池的连接，第三次请求时连接池被占满，无法建立新连接，进而抛出异常。更糟的是，此时抛出的WebException可能没有Response属性（因为请求根本没发出去），后续代码访问null对象就触发了NullReferenceException。

解决这个问题的关键是用using语句自动释放资源，确保每次请求后连接被回收：

[Microsoft.SqlServer.Server.SqlFunction(DataAccess = DataAccessKind.Read)]
public static SqlString HEAD(SqlString Uri)
{
    string statusCode = "";
    string debugData = "1,";
    try
    {
        debugData += "2,";
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
        debugData += "3,";
        
        // 用using包裹HttpWebRequest，自动释放资源
        using (HttpWebRequest req = (HttpWebRequest)WebRequest.Create(Convert.ToString(Uri)))
        {
            req.Method = "HEAD";
            req.AllowAutoRedirect = true;
            debugData += "4,";
            
            // 用using包裹HttpWebResponse
            using (HttpWebResponse resp = (HttpWebResponse)req.GetResponse())
            {
                debugData += "5,";
                if (resp.StatusCode == HttpStatusCode.MethodNotAllowed)
                {
                    debugData += "6,";
                    // 重新发起GET请求时也要用using
                    using (HttpWebRequest reqGet = (HttpWebRequest)WebRequest.Create(Convert.ToString(Uri)))
                    {
                        reqGet.Method = "GET";
                        using (HttpWebResponse respGet = (HttpWebResponse)reqGet.GetResponse())
                        {
                            statusCode = ((int)respGet.StatusCode).ToString();
                        }
                    }
                }
                else
                {
                    statusCode = ((int)resp.StatusCode).ToString();
                }
                debugData += "7,";
                debugData += "8,";
            }
        }
    }
    catch (WebException ex)
    {
        debugData += "9,";
        // 先检查ex.Response是否为null，避免后续访问null对象
        if (ex.Response != null)
        {
            using (HttpWebResponse webResponse = (HttpWebResponse)ex.Response)
            {
                debugData += "10,";
                statusCode = ((int)webResponse.StatusCode).ToString();
                debugData += "11,";
            }
        }
        else
        {
            debugData += "10a,";
            statusCode = $"No response: {ex.Message}";
            debugData += "11a,";
        }
    }
    catch (Exception ex)
    {
        debugData += "12,";
        statusCode = $"{debugData} | {ex.Message}";
        debugData += "13,";
    }
    debugData += "14,";
    return debugData; // 测试完可以改回return statusCode;
}

2. Catch块中的NullReference隐患 #

原来的第一个WebException捕获块里，你直接把ex.Response强制转换为HttpWebResponse，然后访问它的StatusCode。但如果请求完全失败（比如网络断了），ex.Response会是null，此时访问webResponse.StatusCode就会直接抛出NullReferenceException。这个异常会跳出当前catch块，虽然理论上会被第二个catch (Exception)捕获，但如果CLR环境因为资源耗尽已经不稳定，可能无法正常执行完catch逻辑，导致你看不到调试数据。

上面的代码里已经添加了ex.Response != null的检查，避免了这个问题。

3. 额外的SQL Server CLR注意事项 #

• 标量值函数是同步执行的，HTTP请求会阻塞SQL查询，如果你需要频繁调用，建议改用CLR存储过程（或者考虑异步逻辑，但CLR里异步有限制）。
• 你设置了PERMISSION_SET=UNSAFE是必要的（因为要发起网络请求），但要注意安全风险，确保程序集的来源可靠。
• 可以考虑添加简单的重试逻辑，但不要在CLR函数里做过多重试，以免拖慢SQL Server的性能。

按照上面的修改后，应该能解决第三次执行崩溃的问题，同时调试数据也能正常返回，帮你定位后续可能的异常。

内容的提问来源于stack exchange，提问作者Roeland