Birden çok sorgunun karşılaştırması

JOIN sorguları birkaç sorgudan daha mı hızlı? (Ana sorgunuzu çalıştırırsınız ve daha sonra ana sorgunuzdaki sonuçlara göre diğer birçok SELECT çalıştırırsınız)

Soruyorum çünkü onlara katılmak, uygulamamın tasarımını ÇOK karmaşık hale getirecek

Daha hızlılarsa, yaklaşık olarak ne kadar kabaca olabilir? 1.5x ise umrumda değil, ama 10x ise sanırım.

Bu, size özel davanızla ilgili bir cevap veremeyecek kadar belirsizdir. Bir çok şeye bağlı. Jeff Atwood (bu sitenin kurucusu) aslında bu konuda yazdı . Bununla birlikte, çoğunlukla, doğru indekslere sahipseniz ve JOIN'larınızı düzgün bir şekilde yaparsanız, genellikle birkaç seyahatten 1 gezi yapmak daha hızlı olacaktır.

İç birleşimler için, yalnızca eşleşen satırları aldığınız için tek bir sorgu mantıklıdır. Sol birleşimler için birden çok sorgu çok daha iyi ... Yaptığım aşağıdaki ölçütlere bakın:

1. 5 Birleştirmeli tek sorgu

   sorgu: 8.074508 saniye

   sonuç boyutu: 2268000

2. Arka arkaya 5 sorgu

   birleştirilmiş sorgu süresi: 0.00262 saniye

   sonuç boyutu: 165 (6 + 50 + 7 + 12 + 90)

.

Her iki durumda da aynı sonuçları aldığımızı unutmayın (6 x 50 x 7 x 12 x 90 = 2268000)

sol birleşimler gereksiz verilerle katlanarak daha fazla bellek kullanır.

Yalnızca iki tablonun birleşimini yaparsanız bellek sınırı o kadar da kötü olmayabilir, ancak genellikle üç veya daha fazla ve farklı sorgulara değer olur.

Bir yan not olarak, MySQL sunucum uygulama sunucumun hemen yanında ... bu yüzden bağlantı süresi göz ardı edilebilir. Bağlantı süreniz saniyeler içinde ise, belki bir faydası vardır

dürüst

Bu soru eski, ancak bazı kriterler eksik. JOIN'i 2 rakibi ile karşılaştırdım:

• N + 1 sorgu
• 2 sorgu, ikincisi bir WHERE IN(...)veya eşdeğerini kullanarak

Sonuç ortada: MySQL üzerine, JOINolduğu çok daha hızlı. N + 1 sorguları bir uygulamanın performansını önemli ölçüde düşürebilir:

Yani, çok az sayıda farklı, yabancı kayıtlara işaret eden çok sayıda kayıt seçmediğiniz sürece. İşte uç durum için bir kıyaslama:

Bir-çok ilişkiye katılmadığınız sürece, tipik bir uygulamada gerçekleşmesi pek olası değildir, bu durumda yabancı anahtar diğer tabloda yer alır ve ana tablo verilerini birçok kez çoğaltırsınız.

Paket servisi:

• *-To-one ilişkileri için her zaman şunu kullanın: JOIN
• * - çok sayıda ilişki için, ikinci bir sorgu daha hızlı olabilir

Daha fazla bilgi için Medium'daki makaleme bakın .

Aslında bu soruya kendim cevap arıyorum ve verilen cevapları okuduktan sonra sadece DB sorgu performansını karşılaştırmanın en iyi yolunun gerçek dünya sayıları elde etmek olduğunu kabul ediyorum çünkü dikkate alınması gereken birçok değişken var AMA, aynı zamanda, aralarındaki sayıları karşılaştırmanın neredeyse tüm durumlarda iyi sonuç vermediğini düşünüyorum. Demek istediğim, sayılar her zaman kabul edilebilir bir sayı ile karşılaştırılmalı ve kesinlikle birbirleriyle karşılaştırılmamalıdır.

Sorgulamanın bir yolunun 0.02 saniye, diğerinin 20 saniye sürdüğünü anlayabiliyorum, bu çok büyük bir fark. Peki ya sorgulamanın bir yolu 0.0000000002 saniye, diğeri 0.0000002 saniye sürerse? Her iki durumda da, bir yol diğerinden 1000 kat daha hızlıdır, ancak ikinci durumda gerçekten "okkalı" mı?

Alt satırda şahsen gördüğüm gibi: eğer iyi performans gösterirse, kolay çözümü tercih edin.

50.000 satırlık tablodan bir satır seçip 100.000 satırlık tablodan bir satırla birleştirerek hızlı bir test yaptık. Temelde şöyle görünüyordu:

$id = mt_rand(1, 50000);
$row = $db->fetchOne("SELECT * FROM table1 WHERE id = " . $id);
$row = $db->fetchOne("SELECT * FROM table2 WHERE other_id = " . $row['other_id']);

vs

$id = mt_rand(1, 50000);
$db->fetchOne("SELECT table1.*, table2.*
    FROM table1
    LEFT JOIN table1.other_id = table2.other_id
    WHERE table1.id = " . $id);

İki seçim yöntemi 50.000 okuma için 3.7 saniye alırken, JOIN evde yavaş bilgisayarımda 2.0 saniye sürdü. INNER JOIN ve LEFT JOIN fark yaratmadı. Birden fazla satırın getirilmesi (örneğin IN SET kullanılarak) benzer sonuçlar verdi.

Asıl soru şu: Bu kayıtların bire bir ilişkisi veya bire çok ilişkisi var mı?

TLDR Cevabı:

Bire bir ise, JOIN ifade .

Bire çok ise, bir (veya çok) kullanın SELECT sunucu tarafı kod optimizasyonu ile deyimi .

Optimizasyon için Neden ve Nasıl Kullanılır?

SELECTBire çok ilişkiye dayanan büyük bir kayıt grubuna (birleştirme yerine birden çok sorgu ile) JOINsahip olmak, üstel bir bellek sızıntısı sorununa sahip olduğu için optimum verimlilik sağlar . Tüm verileri alın, ardından sıralamak için sunucu tarafı bir komut dosyası dili kullanın:

SELECT * FROM Address WHERE Personid IN(1,2,3);

Sonuçlar:

Address.id : 1            // First person and their address
Address.Personid : 1
Address.City : "Boston"

Address.id : 2            // First person's second address
Address.Personid : 1
Address.City : "New York"

Address.id : 3            // Second person's address
Address.Personid : 2
Address.City : "Barcelona"

Burada, tüm kayıtları bir select deyiminde alıyorum. Bu, JOINbu kayıtların küçük bir grubunu birer birer başka bir sorgunun alt bileşeni olarak almaktan daha iyidir . Sonra bir şey gibi görünen sunucu tarafı kodu ile ayrıştırmak ...

<?php
    foreach($addresses as $address) {
         $persons[$address['Personid']]->Address[] = $address;
    }
?>

Optimizasyon için JOIN kullanılmadığı zaman

JOINTek bir kayıtla bire bir ilişkiye dayanan büyük bir kayıt grubunun birden fazla kayıtla karşılaştırılması, SELECT , bir sonraki kayıt türünü elde etmek için birbiri ardına ifadeye .

Fakat JOIN bire çok ilişkisiyle kayıt alırken verimsizdir.

Örnek: Blog bloglarının 3 ilgi alanı tablosu vardır: Blogpost, Etiket ve Yorum.

SELECT * from BlogPost
LEFT JOIN Tag ON Tag.BlogPostid = BlogPost.id
LEFT JOIN Comment ON Comment.BlogPostid = BlogPost.id;

1 blog yazısı, 2 etiket ve 2 yorum varsa, aşağıdaki gibi sonuçlar alırsınız:

Row1: tag1, comment1,
Row2: tag1, comment2,
Row3: tag2, comment1,
Row4: tag2, comment2,

Her kaydın nasıl kopyalandığına dikkat edin. Tamam, 2 yorum ve 2 etiket 4 satır. 4 yorumumuz ve 4 etiketimiz varsa ne olur? 8 satır almazsınız - 16 satır alırsınız:

Row1: tag1, comment1,
Row2: tag1, comment2,
Row3: tag1, comment3,
Row4: tag1, comment4,
Row5: tag2, comment1,
Row6: tag2, comment2,
Row7: tag2, comment3,
Row8: tag2, comment4,
Row9: tag3, comment1,
Row10: tag3, comment2,
Row11: tag3, comment3,
Row12: tag3, comment4,
Row13: tag4, comment1,
Row14: tag4, comment2,
Row15: tag4, comment3,
Row16: tag4, comment4,

Daha fazla tablo, daha fazla kayıt vb. Ekleyin ve sorun, çoğunlukla gereksiz verilerle dolu yüzlerce satıra hızla şişer .

Bu kopyaların size maliyeti nedir? Bellek (SQL sunucusunda ve kopyaları kaldırmaya çalışan kodda) ve ağ kaynakları (SQL sunucusu ile kod sunucunuz arasında).

Kaynak: https://dev.mysql.com/doc/refman/8.0/en/nested-join-optimization.html ; https://dev.mysql.com/doc/workbench/en/wb-relationship-tools.html

Hem ayrı sorgular hem de birleştirmeler oluşturun, sonra her birini zamanlayın - hiçbir şey gerçek dünya rakamlarından daha fazla yardımcı olmaz.

Daha da iyisi - her sorgunun başına "EXPLAIN" ekleyin. Bu, veri isteğinizi yanıtlamak için MySQL'in kaç alt sorguyu kullandığını ve her sorgu için kaç satır tarandığını gösterir.

Veritabanı karmaşıklığına bağlı olarak geliştirici karmaşıklığına bağlı olarak, birçok SELECT çağrısı yapmak daha kolay olabilir.

JOIN ve birden çok SELECTS için bazı veritabanı istatistikleri çalıştırmayı deneyin. Ortamınızda JOIN'in SELECT'ten daha hızlı / yavaş olup olmadığına bakın.

Sonra tekrar, eğer bir JOIN olarak değiştirmek fazladan bir gün / hafta / ay dev çalışma anlamına gelirse, birden fazla SELECT

Alkış,

BLT

Deneyimlerime göre, özellikle büyük veri kümeleri alırken birkaç sorgu çalıştırmanın genellikle daha hızlı olduğunu fark ettim.

PHP gibi başka bir uygulamadan veri tabanı ile etkileşim kurarken, bir çok sunucuya yapılan bir gezinin argümanı vardır.

Sunucuya yapılan yolculuk sayısını sınırlamanın ve genellikle yalnızca daha hızlı değil aynı zamanda uygulamanın okunmasını kolaylaştıran birden çok sorgu çalıştırmanın başka yolları da vardır - örneğin mysqli_multi_query.

SQL söz konusu olduğunda acemi değilim, geliştiricilerin, özellikle gençler çok zeki birleşimler yazmaya çalışırken çok fazla zaman harcama eğilimi olduğunu düşünüyorum, çünkü akıllı görünüyorlar, oysa veriyi çıkarmanın akıllı yolları var basit.

Son paragraf kişisel bir görüştü, ama umarım bu yardımcı olur. Karşılaştırma yapmanız gerektiğini söyleyenlere rağmen diğerleriyle aynı fikirdeyim. Her iki yaklaşım da gümüş bir kurşun değildir.

Bir birleştirmeyi kullanmanız gerekip gerekmediği her şeyden önce bir birleşimin mantıklı olup olmadığıdır . Sadece bu noktada performans dikkate alınması gereken bir şeydir, çünkü neredeyse tüm diğer durumlar önemli ölçüde daha kötü sonuç verecektir performansa .

Performans farklılıkları büyük ölçüde sorguladığınız bilgilerin ne kadar alakalı olduğuna bağlı olacaktır. Birleşmeler işe yarar ve veriler ilişkilendirildiğinde hızlıdır ve öğeleri doğru bir şekilde dizine , ancak genellikle fazlalık ve bazen gerekenden daha fazla sonuç verir. Ve veri kümeleriniz doğrudan ilişkili değilse, bunları tek bir sorguya yapıştırmak, Kartezyen ürün olarak adlandırılan (temel olarak, tüm olası satır kombinasyonları) ile sonuçlanır, bu da neredeyse hiç istemediğiniz şeydir.

Bu genellikle çoktan bire birçok ilişkiden kaynaklanır. Örneğin, HoldOffHunger'in cevabı yayınlar, etiketler ve yorumlar için tek bir sorgudan bahsetti. Yorumlar, etiketler gibi bir yayınla ilgilidir ... ancak etiketler yorumlarla ilgisizdir.

+------------+     +---------+     +---------+
|  comment   |     |   post  |     |  tag    |
|------------|*   1|---------|1   *|---------|
| post_id    |-----| post_id |-----| post_id |
| comment_id |     | ...     |     | tag_id  |
| user_id    |     |         |     | ...     |
| ...        |     |         |     | ...     |
+------------+     +---------+     +---------+

Bu durumda, bunun en az iki ayrı sorgu olması açık bir şekilde daha iyidir. Etiketler ve yorumlara katılmaya çalışırsanız, ikisi arasında doğrudan bir ilişki olmadığı için, her olası etiket ve yorum kombinasyonuyla sonuçlanırsınız. many * many == manymany. Bunun yanı sıra, yayınlar ve etiketler ilgisiz olduğundan, bu iki sorguyu paralel olarak gerçekleştirerek potansiyel kazanca yol açar.

Yine de farklı bir senaryo düşünelim: Yorumların bir gönderiye ve yorum yapanların iletişim bilgilerine eklenmesini istiyorsunuz.

 +----------+     +------------+     +---------+
 |   user   |     |  comment   |     |   post  |
 |----------|1   *|------------|*   1|---------|
 | user_id  |-----| post_id    |-----| post_id |
 | username |     | user_id    |     | ...     |
 | ...      |     | ...        |     +---------+
 +----------+     +------------+

Burada bir katılmayı düşünmelisiniz. Çok daha doğal bir sorgu olmanın yanı sıra, çoğu veritabanı sistemi (MySQL dahil), birçok akıllı insanın, sorguları optimize etmek için çok fazla çaba harcamasına sahiptir. Ayrı sorgular için, her sorgu bir öncekinin sonuçlarına bağlı olduğundan, sorgular paralel olarak yapılamaz ve toplam süre yalnızca sorguların gerçek yürütme zamanı değil, aynı zamanda sonuçların getirilmesi, eleme için harcanan zaman haline gelir bir sonraki sorgunun kimlikleri, satırları birbirine bağlama vb.

Verim açısından daha hızlı olacak mı? Muhtemelen. Ancak aynı zamanda (veritabanı ve şemanıza bağlı olarak) aynı anda daha fazla veritabanı nesnesini kilitler ve böylece eşzamanlılığı azaltır. Deneyimlerime göre, insanlar veritabanının aynı LAN'da olduğu çoğu OLTP sisteminde gerçekte "daha az veritabanı gidiş-dönüşleri" argümanı tarafından yanıltıcıdır, gerçek darboğaz nadiren ağdır.

İşte 100 yararlı sorgu ile bir bağlantı, bunlar Oracle veritabanında test edilir, ancak SQL, Oracle, MS SQL Server, MySQL ve diğer veritabanları arasında farklılık gösteren bir standart olduğunu unutmayın:

http://javaforlearn.com/100-sql-queries-learn/

İkili cevap olmadığı anlamına gelen birkaç faktör vardır. Performans için neyin en iyi olduğu sorusu ortamınıza bağlıdır. Bu arada, bir tanımlayıcıya sahip tekli seçiminiz ikinci saniye değilse, yapılandırmanızla ilgili bir sorun olabilir.

Sorulması gereken asıl soru verilere nasıl erişmek istediğinizdir. Tekli seçimler geç bağlanmayı destekler. Örneğin, yalnızca çalışan bilgisi istiyorsanız, Çalışanlar tablosundan seçim yapabilirsiniz. Yabancı anahtar ilişkileri, ilgili kaynakları daha sonra ve gerektiğinde almak için kullanılabilir. Seçimlerin zaten gösterilmesi gereken bir anahtarı olacak, bu yüzden son derece hızlı olmalılar ve sadece ihtiyacınız olanı almalısınız. Ağ gecikmesi her zaman dikkate alınmalıdır.

Birleştirmeler tüm verileri bir kerede alır. Bir rapor oluşturuyorsanız veya bir tabloyu dolduruyorsanız, bu tam olarak istediğiniz şey olabilir. Derlenmiş ve opto edilmiş birleştirmeler bu senaryoda tekli seçimlerden daha hızlı olacaktır. Unutmayın, Geçici bağlantılar o kadar hızlı olmayabilir - bunları derlemelisiniz (depolanmış bir procta). Hız yanıtı, DBMS'nin verileri almak için tam olarak hangi adımları attığını gösteren yürütme planına bağlıdır.

Evet, JOINS kullanan bir sorgu daha hızlı olur. Sorguladığınız tabloların ilişkilerini, veri kümenizin boyutunu veya birincil anahtarların nerede olduğunu bilmeden, ne kadar hızlı olduğunu söylemek neredeyse imkansızdır.

Neden her iki senaryoyu da test etmiyorsunuz, o zaman emin olacaksınız ...