可以默认配置/使用sp

10

我正在寻找对SQL Server使用高度动态sql查询的应用程序。查看以非常奇怪和复杂的方式构造的查询，但这是一个不同的故事，我告诉它有一个很好的理由使我无法（太愚蠢）自己发现问题……我看不到查询用换行的任何代码sp_executesql。

但是，当我跟踪时，可以看到很多查询都用包裹了sp_executesql。整个应用程序解决方案甚至根本不包含命令sp_executesql。

因此，我想知道是否存在某种我不知道的配置，该配置默认情况下会强制软件使用sp_executesql包装查询？

什么可能导致这种行为？

sql-server sql-server-2008 dynamic-sql

— 玛吉尔
source

11

打包SQL语句的原因sp_executesql是SqlCommand.Commandtype属性的设置，并将任何参数传递给命令。

SqlCommand cmd = new SqlCommand("proc1", con);
cmd.CommandType = CommandType.StoredProcedure;                
cmd.Parameters.AddWithValue("@param1", 1);
con.Open();
cmd.ExecuteNonQuery();
con.Close();

上面的代码以以下T-SQL结尾：

exec proc1 @param1=1

SqlCommand cmd = new SqlCommand("proc1", con);
cmd.CommandType = CommandType.Text;                
cmd.Parameters.AddWithValue("@param1", 1);
con.Open();
cmd.ExecuteNonQuery();
con.Close();

该代码以执行以下T-SQL结尾：

exec sp_executesql N'proc1',N'@param1 int',@param1=1

添加23.12.15：使用CommandType.Text命令，结果类似：将参数添加到命令对象后，.NET会将整个查询包装到其中sp_executesql并将参数传递给它。

另外：在深入sp_executesql探究之后，参数嗅探和计划缓存对于避免频繁的查询编译和计划数量，.NET类的这种行为完全有意义。因此，其基本目的是确保总体上具有更好的SQL Server性能，同时它可能导致与初始创建的查询计划相比使用不同参数值的某些查询（参数嗅探问题）的性能下降。

看到：

上面的示例是使用.NET Framework 4.5和SQL Server 2008 Developer Edition创建的。

— 玛吉尔
source

5

如果这是.NET应用程序，则很可能是SqlCommand.ExecuteReader（）被调用的结果。根据主要的SqlCommand类页面，在“备注”部分中方法描述的网格中，在ExecuteReader下显示：

执行返回行的命令。为了提高性能，ExecuteReader使用Transact-SQL sp_executesql系统存储过程来调用命令。因此，如果用于执行诸如Transact-SQL SET语句之类的命令，ExecuteReader可能不会具有您想要的效果。

我现在没有时间进行测试以确认其描述，但是创建一个简单的控制台应用程序应该足够容易，该应用程序可以进行非常简单的调用，传递一些查询文本，并包括随提供的参数SqlParameter。我的猜测是ExecuteNonQuery并且ExecuteScalar还可以使用sp_executesql它们，因为它们还允许传递参数，那么为什么会有不同的路径执行这些参数呢？

— 所罗门·鲁兹基
source

可以默认配置/使用sp_executesql吗？