Burada yaşadığımız en büyük problemler:
- @JNK'nin dediği gibi, SQL Server bir UDF kullanımını gizler ve yine de onlarla korkunç şeyler yapar (her zaman bir satır tahmin eder gibi). SSMS'de gerçek bir plan oluşturduğunuzda, onun da kullanımını görmezsiniz. Yalnızca SQL Server'ın sağladığı bir plan hakkında bilgi sağlayabildiği için Plan Gezgini aynı sınırlamalara tabidir.
- Kod, gerçek bir plan oluştururken çalışma zamanı metrikleri için farklı kaynaklara dayanır. Ne yazık ki plan XML işlev çağrıları içermez ve SQL Server, herhangi bir işlev kullanılırken bir işlevin neden olduğu G / Ç'yi göstermez
SET STATISTICS IO ON;( Table I/Osekme bu şekilde doldurulur).
AdventureWorks2012'ye karşı aşağıdaki görünümü ve işlevi göz önünde bulundurun. Bu, başlık tablosundan rastgele bir satır verilen ayrıntı tablosundan rastgele bir satır döndürmeye yönelik aptalca bir girişimdir - çoğunlukla her seferinde mümkün olduğunca çok G / Ç oluşturduğumuzdan emin olmak için.
CREATE VIEW dbo.myview
WITH SCHEMABINDING
AS
SELECT TOP (100000) rowguid, SalesOrderID, n = NEWID()
FROM Sales.SalesOrderDetail ORDER BY NEWID();
GO
CREATE FUNCTION dbo.whatever(@SalesOrderID INT)
RETURNS UNIQUEIDENTIFIER
WITH SCHEMABINDING
AS
BEGIN
RETURN
(
SELECT TOP (1) rowguid FROM dbo.myview
WHERE SalesOrderID = @SalesOrderID ORDER BY n
);
END
GO
Management Studio Ne Söylüyor (Ve Vermiyor)
SSMS'de aşağıdaki sorguyu alın:
SET STATISTICS IO ON;
SELECT TOP (5) SalesOrderID, dbo.whatever(SalesOrderID)
FROM Sales.SalesOrderHeader ORDER BY NEWID();
SET STATISTICS IO OFF;
Bir plan tahmin zaman, sorgu için bir plan almak ve bir tek fonksiyon için planı (umut edebileceğiniz gibi, değil 5):
Sorgu gerçekten yürütülmediği için hiçbir G / Ç verisi alamazsınız. Şimdi gerçek bir plan oluşturun. Sonuçlar tablosunda beklediğiniz 5 satırı alırsınız , aşağıdaki plan (UDF'den kesinlikle gözle görülür bir şekilde bahsedilmez, XML dışında bunu sorgu metninin bir parçası olarak ve Skaler Operatörün bir parçası olarak bulabilirsiniz):
Ve aşağıdaki STATISTICS IOçıktı ( bu tablodan okumak zorundaSales.SalesOrderDetail olduğunu bilmemize rağmen, kesinlikle hiçbir şeyden söz etmiyor ):
'SalesOrderHeader' tablosu. Tarama sayısı 1, mantıksal okumalar 57, fiziksel okumalar 0, ileri okumalar 0, lob mantıksal okumalar 0, lob fiziksel okumalar 0, lob okuma öncesi okumalar 0.
Plan Gezgini Size Ne Söylüyor
PE aynı sorgu için tahmini bir plan oluşturduğunda, SSMS ile aynı şeyi bilir. Ancak, işleri biraz daha sezgisel bir şekilde gösterir. Örneğin, dış sorgu için tahmini plan, işlevin çıktısının sorgu çıktısıyla nasıl birleştirildiğini gösterir ve her iki tabloda da G / Ç'nin olduğu hemen anlaşılır :
Ayrıca işlevin planını tek başına gösterir , ki bu sadece bütünlük için dahil ediyorum:
Şimdi, binlerce kat daha yararlı olan gerçek bir plana bakalım. Buradaki dezavantaj, yine, sadece SQL Server'ın göstermeye karar verdiği bilgilere sahiptir, bu nedenle sadece SQL Server'ın sağladığı grafik plan diyagramlarını gösterebilir. Bu, birinin size yararlı bir şey göstermemeye karar verdiği bir durum değildir; sağlanan XML planına dayanarak bu konuda hiçbir şey bilmiyor. Bu durumda, tıpkı SSMS'de olduğu gibi , sadece dış sorgunun planını görebilirsiniz ve sanki fonksiyon hiç çağrılmıyormuş gibi :
Tablo G / Ç sekmesi de, yineSTATISTICS IO de işlev çağrısında gerçekleştirilen etkinliklerden herhangi birini göz ardı eden çıktısına dayanır :
Ancak, PE tüm çağrı yığınını sizin için alır. İnsanların ara sıra "Pffft, çağrı yığınına ne zaman ihtiyacım olacak?" Diye sorduğunu duydum. Aslında, her bir işlev çağrısı için harcanan zamanı, CPU'yu ve okuma sayısını (ve TVF'ler için üretilen satır sayısını) ayırabilirsiniz :
Ne yazık ki, G / Ç'nin hangi tablo (lar) dan geldiğini (SQL Server bu bilgiyi vermediği için) ve UDF adıyla etiketlenmediğini ilişkilendirme olanağınız yoktur. (çünkü işlev çağrısının kendisini değil, geçici bir ifade olarak yakalanır). Ama Management Studio'nun görmediğini görmenizi sağlayan şey, UDF'nizin ne bir köpek olduğu. Hala bazı noktalara katılmalısın, ama daha az nokta var ve birbirlerine daha yakınlar.
Profiler Hakkında
Son olarak, komut dosyası yazacağınız ve daha sonra herhangi bir UI aracının kapsamının dışında çalıştıracağınız bir sunucu tarafı izi ayarlamak sürece Profiler'den uzak durmanızı şiddetle tavsiye ederim. Profiler'ı bir üretim sistemine karşı kullanmak, neredeyse hiç çözemeyeceğinden daha fazla soruna yol açacaktır . Bu bilgileri almak istiyorsanız, lütfen sunucu tarafı izleme veya genişletilmiş etkinlikler kullanın ve çok akıllıca filtrelediğinizden emin olun. Profil oluşturucusuz bile, bir izleme sunucunuzu etkileyebilir ve genişletilmiş etkinlikler aracılığıyla showplans almak dünyadaki en verimli şey değildir .