Sp_executesql varsayılan olarak yapılandırılabilir / kullanılabilir mi?

SQL Server karşı son derece dinamik sql sorguları kullanan bir uygulamaya bakıyorum. Çok garip ve karmaşık yollarla yapılan sorgulara bakıyorum, ama bu farklı bir hikaye, kendime bir şeyler bulamamam (çok aptal) olmam için iyi bir neden vermesini söylüyorum ... Göremiyorum sorguların sarıldığı herhangi bir kod sp_executesql.

Ancak izlediğimde, çok fazla sorgunun geldiğini görebiliyorum sp_executesql. Tüm uygulama çözümü komutu bile içermez sp_executesql.

Bu yüzden yazılım varsayılan olarak sp_executesql ile sorguları sarmak için zorlar bilmiyorum bir yapılandırma türü merak ettiniz mi?

Bu davranışa ne sebep olabilir?

SQL deyimlerinin paketlenmesinin nedeni, özelliğin sp_executesqlayarlanması ve herhangi bir Parametrenin komuta iletilmesidir.SqlCommand.Commandtype

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

Yukarıdaki kod bu T-SQL ile biter:

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();

Bu kod, aşağıdaki T-SQL'in yürütülmesi ile sona erer:

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

Ek 23.12.15: Bir CommandType.Textkomut kullanarak sonuçlar benzer: Komut nesnesine bir parametre eklenir eklenmez, .NET tüm sorguyu sarar sp_executesqlve parametreleri ona iletir .

Ekleme: Daha derinlemesine daldıktan sonra sp_executesql, parametre koklama ve .NET sınıflarının bu davranışını önbelleğe almanın planlanması, yüksek sık sorgu derlemesi ve plan sayısından kaçınmak için tamamen mantıklıdır. Bu nedenle, temel olarak daha iyi bir SQL Server performansı sağlamak için tasarlanmıştır, ancak aynı zamanda ilk oluşturulan sorgu planından farklı parametre değerleriyle kullanılan bazı sorguların (parametre koklama sorunu) düşük performansına yol açabilir.

Görmek:

• 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

Yukarıdaki örnek, .NET Framework 4.5 ve SQL Server 2008 Developer Edition kullanılarak oluşturuldu.

Bu bir .NET uygulamasıysa, büyük olasılıkla SqlCommand.ExecuteReader () çağrılmasının bir sonucudur . Ana SqlCommand sınıf sayfasına göre, "Açıklamalar" bölümündeki yöntem açıklamaları kılavuzunda ExecuteReader altında şöyle yazar:

Satırları döndüren komutları yürütür. Performansı artırmak için ExecuteReader, Transact-SQL sp_executesql sistem saklı yordamını kullanarak komutları çağırır . Bu nedenle, Transact-SQL SET deyimleri gibi komutları yürütmek için kullanılırsa ExecuteReader istediğiniz etkiye sahip olmayabilir.

Şimdi açıklamasını onaylamak için bunu test etmek için zamanım yok, ama çok basit bir çağrı yapan, bazı sorgu metnini geçen ve bir ile birlikte verilen bir parametre de dahil olmak üzere basit bir konsol uygulaması oluşturmak için yeterince kolay olmalıdır SqlParameter. Benim tahminim bu ExecuteNonQueryve ExecuteScalaraynı sp_executesqlzamanda parametrelerin geçişine izin verdikleri için de kullanıyorum , bu yüzden bunların nasıl yürütüldüğü için neden farklı bir yol olacak?