Implicit Conversion nedir? #QueryOptimization

Yunus UYANIK
Nov 20, 2019 · 3 min read

Implicit Conversion yine execution planlarda sık karşılaşılan ancak genelde umursanmayan ya da performansa olan etkisi bilinmeyen bir uyarıdır.

Ne zaman oluşur?

Tip dönüşümleri yapıldığında ya da SQL Engine’in tip dönüşümü yapmaya zorlandığı durumlarda ortaya çıkar. Karşılaşmak istemediğimiz, kolay çözülebilen ancak frequency query’lerde olduğu zaman SQL Server’ın CPU’suna büyük yük getirebilecek bir uyarıdır kendileri.

StackOverFlow veritabanı üzerinde Badges tablosunda örneğimi yapacağım.

İşte tablo tasarımı;

Şöyle bir örnek ile başlayalım ;

SET STATISTICS IO,TIME ON
DECLARE @Name_VARCHAR VARCHAR(100) = 'Teacher'
SELECT Name FROM [dbo].[Badges_VARCHAR] WHERE Name = @Name_VARCHAR

Alanımın tipi zaten VARCHAR olduğundan 101241 satır getirmek için IX_Name adındaki oluşturmuş olduğum index’e SEEK yaptı.

  • Okunan page sayısı : 319
  • Execute süresi : 566ms
  • CPU tüketimi : 31ms
DECLARE @Name_NVARCHAR NVARCHAR(100) = N'Teacher'SELECT Name FROM [dbo].[Badges_VARCHAR] WHERE Name = @Name_NVARCHAR

Değişkenimi NVARCHAR olarak değiştirip tip uyuşmazlığına yol açtığımda, 101241 satır getirmek için IX_Name index’ine SCAN işlemi yapmayı tercih ediyor ve bu sebeple değerlerimiz artıyor.

Ayrıca bir warning var. SQL Engine’in conversion işleminden dolayı plan seçiminin etkilenebileceğini söylüyor.

Evet. Tebrikler SQL doğru bildin.

  • Okunan page sayısı : 3752
  • Execute süresi : 718ms
  • CPU tüketimi : 188ms

Bu örnekte yanlış plan seçimi yapan bir sorguyla conversion işlemine baktık. Bir de planı değişmeyen bir sorguyla devam edelim.

DECLARE @UserId_INT INT =3718SELECT UserId FROM Badges WHERE UserId = @UserId_INTDECLARE @UserId_VARCHAR VARCHAR(100) = '3718'SELECT UserId FROM Badges WHERE UserId = @UserId_VARCHAR

İki sorgumuzda da aynı index’i seek yaptı, okuma değerlerimiz değişmedi. Sadece conversion’ın olduğu sorguda ufak bir warning var.

SQL Server’ı biraz zorlayalım o halde.

SQLQueryStress kullanarak bir test yapıyorum. Her sorguyu 10 koldan gönderiyorum. Okunan page değerlerinde bir değişiklik olmamasına rağmen CPU tüketimi ve sorgu sürelerinin uzamış olduğunu gözlemliyorum.

  • CPU tüketimi : 0.0015 > 0.0037
  • Execute süresi : 07.6405 > 09.2813

Not : Query’ler çalıştırılmadan önce plan belleği temizlenmiştir.

Küçük farklar gibi gözükse de canlı ortamlarda ve başta dediğim gibi frequency yüksek olan sorgularda acı verebilecek bir problem. Tecrübelerim kadarıyla genelde varchar kolonlara nvarchar değişken gönderim örneği daha fazla yaşanıyor, ve yine genelde bu sorgular linq vb. tarafından üretilen sorgularda oluyor.

Ve microsoft’ta da bulabileceğin conversion tablosu;

Yunus UYANIK

Written by

I am Microsoft SQL Database Consultant. I have been providing performance tuning solutions to my clients who need their sql servers to run faster.

More From Medium

Also tagged Performance Tuning

Also tagged Performance Tuning

High Volume Incoming Connections

103

Also tagged Sql

Related reads

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade