4

非常简短的背景：我们正在使用 CLR 存储过程来应用访问控制，使用 Active Directory 对查询结果进行限制，以相应地限制最终用户可以看到的内容。简而言之，这是通过从数据表中删除用户不满足访问结果（在本例中为文档）的标准的行来完成的。

在显示结果之前，此过滤先前已在客户端上完成。SQL 2008 和更强大的服务器是将此访问过滤移出客户端的动机。

我想知道的是，从等效的 CLR 存储过程调用原始常规 T-SQL 存储过程是否有任何性能优势，而不是将“内联”T-SQL 传递给命令对象（在这种情况下只是作为存储过程的原始 T-SQL）？我找不到有人提到这一点的任何地方（部分原因可能是因为它作为 CLR SP 的示例会非常令人困惑，我猜 :-)）。在我看来，您可能会因为 T-SQL 存储过程已经被优化和编译？

有人可以为我确认吗？

希望我已经足够清楚了。非常感谢，

科尔姆。

4

1 回答 1

0

如果您的 SQL CLR 存储过程正确执行特定查询（很好地参数化）并且相当频繁地执行它，那么该 T-SQL 查询将只在整个“确定最佳执行计划”序列中运行一次，然后存储在计划缓存中您的 SQL Server （并且不会比类似的 T-SQL 存储过程更快地从它驱逐）。

因此，它将与原始 T-SQL 存储过程一样“预编译”。从这个角度来看，我没有看到任何好处。

如果您可以在 SQL CLR 过程中调整您的 SQL 语句，使其实际上甚至不会将这些行包含到您最终会丢弃的结果集中，那么您的 SQL-CLR 存储过程将执行正确参数化的 T-SQL 查询甚至可能比让标准 T-SQL 存储过程返回太多需要再次排除某些行的数据快一点。

于 2011-12-17T20:29:12.830 回答