Sp_executesql può essere configurato / utilizzato per impostazione predefinita?

Sto guardando un'applicazione che utilizza query sql altamente dinamiche su SQL Server. Guardando le domande che sono costruite in modi molto strani e complicati, ma questa è una storia diversa, lo dico per dare una buona ragione per cui non sono in grado (troppo stupido) di scoprire le cose da solo ... Non riesco a vedere qualsiasi codice in cui sono racchiuse le query sp_executesql.

Ma quando traccio, riesco a vedere un sacco di domande in arrivo sp_executesql. L'intera soluzione applicativa non contiene nemmeno il comando sp_executesql.

Quindi mi chiedevo se esiste un tipo di configurazione che non conosco ancora che impone al software di avvolgere le query con sp_executesql per impostazione predefinita?

Cosa potrebbe causare questo comportamento?

Il motivo per cui le istruzioni SQL vengono raggruppate sp_executesqlè l'impostazione della SqlCommand.Commandtypeproprietà e il passaggio di qualsiasi parametro al comando.

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

Il codice sopra termina con questo 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();

Questo codice termina con l'esecuzione del seguente T-SQL:

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

Aggiunta 23.12.15: Usando un CommandType.Textcomando, i risultati sono simili: Non appena un parametro viene aggiunto all'oggetto comando, .NET avvolgerà l'intera query sp_executesqle gli passerà i parametri.

Aggiunta: Dopo un'analisi più approfondita sp_executesql, lo sniffing dei parametri e la memorizzazione nella cache dei piani di questo comportamento delle classi .NET hanno perfettamente senso al fine di evitare compilazioni di query frequenti e numero di piani. Quindi è sostanzialmente progettato per garantire una migliore prestazione di SQL Server in generale, mentre allo stesso tempo potrebbe portare a scarse prestazioni di alcune query (problema di sniffing dei parametri) che vengono utilizzate con valori di parametri diversi rispetto al piano di query creato inizialmente.

Vedere:

• https://blogs.technet.microsoft.com/mdegre/2011/11/06/what-is-parameter-sniffing/
• http://sqlmag.com/database-performance-tuning/don-t-fear-dynamic-sql
• http://www.sqlskills.com/blogs/kimberly/exec-and-sp_executesql-how-are-they-different
• http://www.brentozar.com/archive/2013/06/optimize-for-unknown-sql-server-parameter-sniffing/
• https://sqlblog.org/2011/09/17/bad-habits-to-kick-using-exec-instead-of-sp_executesql

L'esempio sopra è stato creato utilizzando .NET Framework 4.5 e SQL Server 2008 Developer Edition.

Se si tratta di un'applicazione .NET, è molto probabile che venga chiamato SqlCommand.ExecuteReader () . Secondo la pagina principale della classe SqlCommand , nella griglia delle descrizioni dei metodi nella sezione "Note", sotto ExecuteReader si dice:

Esegue i comandi che restituiscono righe. Per migliorare le prestazioni, ExecuteReader richiama i comandi utilizzando la stored procedure di sistema Transact-SQL sp_executesql . Pertanto, ExecuteReader potrebbe non avere l'effetto desiderato se utilizzato per eseguire comandi come le istruzioni SET Transact-SQL.

Non ho tempo ora per testare questo per confermare la loro descrizione, ma dovrebbe essere abbastanza facile creare una semplice app console che fa una chiamata molto semplice, passando un po 'di testo di query e includendo un parametro che viene fornito con un SqlParameter. La mia ipotesi è che ExecuteNonQuerye ExecuteScalaranche usare sp_executesqlpoiché consentono anche il passaggio di parametri, quindi perché dovrebbe esserci un percorso diverso per come vengono eseguiti?