SQL 'gibi' vs '=' performansı

Bu soru merak ettiklerimin etrafında dönüyor, ancak cevaplar tam olarak onu ele almıyor.

Gibi görünüyor genel olarak '=' daha hızlı joker kullanırken 'gibi' olduğunu. Bu geleneksel bilgelik gibi görünüyor. Ancak, sınırlı sayıda farklı sabit, kodlanmış, varchar tanımlayıcı içeren bir sütunum olduğunu ve bunlardan biriyle eşleşen tüm satırları seçmek istediğimi varsayalım:

select * from table where value like 'abc%'

ve

select * from table where value = 'abcdefghijklmn'

'Beğen' bir eşleşme bulmak için yalnızca ilk üç karakteri test etmelidir, oysa '=' tüm dizeyi karşılaştırmalıdır. Bu durumda, bana 'beğenmek' bir avantaja sahip olacak gibi görünüyor, diğer tüm şeyler eşittir.

Bu genel, akademik bir soru olarak düşünülmüştür ve bu nedenle hangi DB'nin önemi olmamalıdır, ancak SQL Server 2005 kullanılarak ortaya çıkmıştır.

Bkz. Https://web.archive.org/web/20150209022016/http://myitforum.com/cs2/blogs/jnelson/archive/2007/11/16/108354.aspx

Oradan alıntı yapın:

LIKE ile dizin kullanımına ilişkin kurallar genel olarak şu şekildedir:

• Filtre ölçütleriniz eşittir = kullanıyorsa ve alan dizine alınmışsa, büyük olasılıkla bir INDEX / CLUSTERED INDEX SEEK kullanacaktır.

• Filtre ölçütleriniz, joker karakter içermeyen LIKE kullanıyorsa (örneğin, bir web raporunda bir parametreniz OLABİLİR, ancak bunun yerine tam dizeyi kullanırsanız), dizini kullanma olasılığı yaklaşık 1 numaradır. Artan maliyet neredeyse hiçbir şeydir.

• Filtre kriterleriniz LIKE kullanıyorsa, ancak başında bir joker karakter varsa (Name0 LIKE '% UTER' gibi) dizini kullanma olasılığı çok düşüktür, ancak yine de tam veya kısmi bir aralıkta en azından bir INDEX SCAN gerçekleştirebilir. İçerik.

• ANCAK, filtre kriterleriniz LIKE kullanıyorsa, ancak İLK STRING ile başlıyorsa ve bundan SONRA bir yerde joker karakterler varsa (Name0 GİBİ 'COMP% ER' gibi), o zaman SQL aynı ilk satırları hızlıca bulmak için bir INDEX SEEK kullanabilir. başlangıç ​​karakterleri ve ardından tam eşleşme için bu satırlara bakın.

(Ayrıca, sorgunuzda başka neler olup bittiğine ve hangi tablolara katıldığınıza bağlı olarak SQL motorunun hala beklediğiniz şekilde bir dizin kullanmayabileceğini unutmayın. SQL motoru, dizini yeniden yazma hakkını saklı tutar. Verileri en verimli olduğunu düşündüğü ve bir INDEX SEEK yerine bir INDEX SCAN içerebilecek şekilde almak için biraz sorgulayın)

Ölçülebilir bir fark.

Aşağıdakileri çalıştırın:

Create Table #TempTester (id int, col1 varchar(20), value varchar(20))
go

INSERT INTO #TempTester (id, col1, value)
VALUES
(1, 'this is #1', 'abcdefghij')
GO

INSERT INTO #TempTester (id, col1, value)
VALUES
(2, 'this is #2', 'foob'),
(3, 'this is #3', 'abdefghic'),
(4, 'this is #4', 'other'),
(5, 'this is #5', 'zyx'),
(6, 'this is #6', 'zyx'),
(7, 'this is #7', 'zyx'),
(8, 'this is #8', 'klm'),
(9, 'this is #9', 'klm'),
(10, 'this is #10', 'zyx')
GO 10000

CREATE CLUSTERED INDEX ixId ON #TempTester(id)CREATE CLUSTERED INDEX ixId ON #TempTester(id)

CREATE NONCLUSTERED INDEX ixTesting ON #TempTester(value)

Sonra:

SET SHOWPLAN_XML ON

Sonra:

SELECT * FROM #TempTester WHERE value LIKE 'abc%'

SELECT * FROM #TempTester WHERE value = 'abcdefghij'

Ortaya çıkan uygulama planı, size ilk operasyonun maliyetinin, yani LIKEkarşılaştırmanın, karşılaştırmadan yaklaşık 10 kat daha pahalı olduğunu gösterir =.

Bir =karşılaştırma kullanabiliyorsanız , lütfen kullanın .

Ayrıca likebazı sql çeşitlerinin indeksleri görmezden geleceğini ve bunun performansı düşüreceğini unutmamalısınız . Bu, özellikle örneğiniz gibi "şununla başlar" kalıbını kullanmazsanız geçerlidir.

Sorgu için yürütme planına gerçekten bakmalı ve ne yaptığını görmelisiniz, mümkün olduğunca az tahmin etmelisiniz.

Bununla birlikte, "ile başlar" kalıbı sql sunucusunda olabilir ve optimize edilmiştir. Bu olacak tablo dizinini kullanırız. EF 4.0'a geçiş likeiçin StartsWithbu çok nedenle.

Eğer valueAktar, yani bir tablo-tarama hem sonucu. Bu senaryodaki performans farkı ihmal edilebilir düzeyde olacaktır.

Eğer valuedizine Daniel onun yorumunda işaret ettiği gibi, =O (log N) performanstır bir dizin arama sonuçlanacaktır. LIKE (büyük olasılıkla - ne kadar seçici olduğuna bağlı olarak) dizinin kısmi bir taramasıyla sonuçlanacak >= 'abc've < 'abd'bu da =.

Burada SQL Server'dan bahsettiğime dikkat edin - tüm DBMS'ler LIKE ile hoş olmayacak.

Yanlış soruyu soruyorsunuz. Veritabanlarında hususlar, her zaman olduğu operatör performansı değil SARGability ekspresyonunun ve coverability genel sorgunun. Operatörün performansı büyük ölçüde önemsizdir.

Öyleyse, SARGability açısından nasıl yapılır LIKEve =karşılaştırılır? LIKE, bir sabitle başlamayan bir ifadeyle kullanıldığında (örneğin kullanıldığında LIKE '%something'), SARGabale dışıdır. Ama bu yapar mı =yoksa LIKE 'something%'SARGable mı? Hayır. SQL performansı ile ilgili herhangi bir soruda olduğu gibi, cevap metnin sorgusunda değil, dağıtılan şemada yatmaktadır. Bunlar ifade edebilir SARGable olmak eğer bir dizin onları tatmin etmek vardır.

Yani, doğruyu söylemek gerekirse, =ve arasında küçük farklar var LIKE. Ancak bir operatörün veya başka bir operatörün SQL'de 'daha hızlı' olup olmadığını sormak, 'Hangisi daha hızlı, kırmızı araba mı mavi araba mı?' Diye sormak gibidir. Renk hakkında değil, motor boyutu ve araç ağırlığı hakkında sorular sormalısınız ... İlişkisel tabloları optimize etme ile ilgili sorulara yaklaşmak için bakmanız gereken yer , WHERE cümlesindeki (ve diğer tümcelerdeki ifadeleriniz ve dizinlerinizdir , ancak bunlar genellikle WHERE ile başlar).

Mysql 5.5 kullanan kişisel bir örnek: 2 tablo arasında, 3 milyon satırdan biri ve 10 bin satırdan biri arasında bir iç birleşim vardı.

Aşağıdaki gibi bir dizinde beğeni kullanırken (joker karakter yok), yaklaşık 30 saniye sürdü:

where login like '12345678'

'açıkla' kullanarak şunu elde ederim:

Aynı sorguda bir '=' kullanıldığında, yaklaşık 0,1 saniye sürdü:

where login ='600009'

"Açıkla" yı kullanarak şunu elde ederim:

Gördüğünüz gibi like, dizin aramasını tamamen iptal etti, bu nedenle sorgu 300 kat daha fazla zaman aldı.

Belki Tam Metin Arama ile ilgileniyorsunuz .

Tam metin aramanın aksine, LIKE Transact-SQL koşulu yalnızca karakter kalıpları üzerinde çalışır. Ayrıca, biçimlendirilmiş ikili verileri sorgulamak için LIKE koşulunu kullanamazsınız. Ayrıca, büyük miktarda yapılandırılmamış metin verisine yönelik bir LIKE sorgusu, aynı verilere yönelik eşdeğer bir tam metin sorgusundan çok daha yavaştır . Milyonlarca metin verisi satırına yönelik LIKE sorgusunun döndürülmesi dakikalar alabilir; tam metin sorgusu ise, döndürülen satır sayısına bağlı olarak aynı verilere karşı yalnızca birkaç saniye veya daha kısa sürebilir.

Her şey sırayla ,

her zaman eşit değiller

    select 'Hello' from dual where 'Hello  ' like 'Hello';

    select 'Hello' from dual where 'Hello  ' =  'Hello';

işler her zaman eşit olmadığında, performansları hakkında konuşmak o kadar da önemli değildir.

Dizeler üzerinde çalışıyorsanız ve yalnızca karakter değişkenleri varsa, performans hakkında konuşabilirsiniz. Ancak genel olarak birbirinin yerine "=" ve "beğen" kullanmayın.

Birçok yayında (yukarıdaki ve diğer sorularda) görmüş olacağınız gibi, eşit oldukları durumlarda, benzerlerin performansı, desen eşleştirme (harmanlama) nedeniyle daha yavaş.