O motivo pelo qual as instruções SQL estão sendo agrupadas sp_executesqlé a configuração da SqlCommand.Commandtypepropriedade e a passagem de qualquer Parâmetro para o comando.
SqlCommand cmd = new SqlCommand("proc1", con);
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.AddWithValue("@param1", 1);
con.Open();
cmd.ExecuteNonQuery();
con.Close();
O código acima termina com este 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();
Este código termina com a execução do seguinte T-SQL:
exec sp_executesql N'proc1',N'@param1 int',@param1=1
Adição 23.12.15: Usando um CommandType.Textcomando, os resultados são semelhantes: Assim que um parâmetro é adicionado ao objeto de comando, o .NET agrupa toda a consulta sp_executesqle passa os parâmetros para ela.
Além disso: após aprofundar sp_executesql, o sniffing de parâmetros e o armazenamento em cache de plano esse comportamento das classes .NET fazem totalmente sentido, a fim de evitar a compilação de consultas freqüentes e o número de planos. Portanto, ele foi basicamente projetado para garantir um melhor desempenho do SQL Server em geral, ao mesmo tempo em que pode levar a um desempenho ruim de algumas consultas (problema de detecção de parâmetro) usadas com valores de parâmetro diferentes do plano de consulta criado inicialmente.
Vejo:
O exemplo acima foi criado usando o .NET Framework 4.5 e o SQL Server 2008 Developer Edition.
