Katılın ve alt sorgu

Ben eski okul MySQL kullanıcısıyım ve her zaman JOINalt sorgu yerine tercih ettim . Ama günümüzde herkes alt sorguyu kullanıyor ve bundan nefret ediyorum; Neden bilmiyorum.

Herhangi bir fark varsa kendime bakacak teorik bilgiye sahip değilim. Bir alt sorgu bir kadar iyi JOINmidir ve bu nedenle endişelenecek bir şey yok mu?

MySQL kılavuzundan alınmıştır ( 13.2.10.11 Alt Sorguları Birleşim Olarak Yeniden Yazma ):

Bir LEFT [OUTER] JOIN eşdeğer bir alt sorgudan daha hızlı olabilir, çünkü sunucu onu daha iyi optimize edebilir - bu sadece MySQL Server'a özgü değildir.

Bu nedenle alt sorgular daha yavaş olabilir LEFT [OUTER] JOIN, ancak bence güçleri biraz daha yüksek okunabilirlik.

Alt sorgular, "A'dan gerçekleri al, B'den gerçeklere koşullu" formundaki sorunları çözmenin mantıksal olarak doğru yoludur. Bu gibi durumlarda, B'yi bir alt sorguda birleştirmek birleştirmekten daha mantıklıdır. Pratik anlamda da daha güvenlidir, çünkü B'ye karşı çoklu maçlar nedeniyle A'dan tekrarlanan gerçekleri almak konusunda dikkatli olmanız gerekmez.

Bununla birlikte, pratik olarak, cevap genellikle performansa iner. Bazı optimize ediciler bir alt sorguya karşı birleştirme verildiğinde limon emer, bazıları ise diğer yolla limon emer ve bu, optimizere özgü, DBMS sürümüne özgü ve sorguya özgüdür.

Tarihsel olarak, açık birleşimler genellikle kazanır, bu nedenle birleşmelerin daha iyi olduğu bilgelik kazanır, ancak optimizatörler her zaman daha iyi hale gelir ve bu nedenle önce mantıksal olarak tutarlı bir şekilde sorgular yazmayı ve sonra performans kısıtlamaları bunu gerektiriyorsa yeniden yapılandırmayı tercih ederim.

Çoğu durumda JOINs alt sorgulardan daha hızlıdır ve bir alt sorgunun daha hızlı olması çok nadirdir.

In JOINRDBMS, sorgunuz için daha iyi bir yürütme planı oluşturabilir ve tüm sorguları çalıştıracağı ve işlem yapmak için tüm verilerini yükleyeceği alt sorgunun aksine, hangi verilerin işlenmesi gerektiğini tahmin edebilir ve zamandan tasarruf edebilir. .

Alt sorgularda iyi olan şey, JOINs'den daha okunabilir olmalarıdır : bu nedenle çoğu yeni SQL insanının bunları tercih etmesi; bu kolay yol; ancak performans söz konusu olduğunda, JOINS çoğu zaman okunması zor olmasa da daha iyidir.

Veritabanınızın sorgunuzu verilerinizde nasıl yürüttüğünü görmek için EXPLAIN kullanın. Bu cevapta büyük bir "duruma bağlı" var ...

PostgreSQL bir alt sorguyu bir birleşime yeniden birleştirebilir veya bir alt sorguyu birleştirerek diğerinden daha hızlı olduğunu düşünebilir. Her şey verilere, dizinlere, korelasyona, veri miktarına, sorguya vb. Bağlıdır.

2010 yılında bu soruların yazarına katılırdım ve kesinlikle oy verirdim JOIN, ancak çok daha fazla deneyimle (özellikle MySQL'de) şunu söyleyebilirim: Evet alt sorgular daha iyi olabilir. Burada birden fazla cevap okudum; belirtilen bazı alt sorgular daha hızlıdır, ancak iyi bir açıklaması yoktu. Umarım bu (çok) geç cevabı verebilirim:

Her şeyden önce, en önemlisi şunu söyleyeyim: Farklı alt sorgu formları var

Ve ikinci önemli ifade: Boyut önemlidir

Alt sorgular kullanıyorsanız , DB-Server'ın alt sorguyu nasıl yürüttüğünün farkında olmalısınız . Özellikle alt sorgu bir veya her satır için değerlendirilirse! Öte yandan, modern bir DB-Server çok şey optimize edebilir. Bazı durumlarda bir alt sorgu bir sorguyu optimize etmeye yardımcı olur, ancak DB-Server'ın daha yeni bir sürümü optimizasyonu geçersiz kılabilir.

Select-Fields'deki alt sorgular

SELECT moo, (SELECT roger FROM wilco WHERE moo = me) AS bar FROM foo

Kaynaktan sonuçlanan her satır için bir alt sorgu yürütüldüğünü unutmayın foo.
Mümkünse bundan kaçının; büyük veri kümelerinde sorgunuzu büyük ölçüde yavaşlatabilir. Ancak, alt sorgunun hiçbir başvurusu yoksa foo, DB sunucusu tarafından statik içerik olarak en iyi duruma getirilebilir ve yalnızca bir kez değerlendirilebilir.

Where-ifadesindeki alt sorgular

SELECT moo FROM foo WHERE bar = (SELECT roger FROM wilco WHERE moo = me)

Şanslıysanız, DB bunu dahili olarak bir JOIN. Değilse, sorgunuz büyük veri kümelerinde çok, çok yavaş olur, çünkü fooyalnızca select türündeki sonuçları değil, her satır için alt sorguyu yürütür .

Join deyimindeki alt sorgular

SELECT moo, bar 
  FROM foo 
    LEFT JOIN (
      SELECT MIN(bar), me FROM wilco GROUP BY me
    ) ON moo = me

Bu ilginç. JOINBir alt sorgu ile birleştiriyoruz . Ve burada alt sorguların gerçek gücünü elde ediyoruz. Milyonlarca satır içeren wilcoancak sadece birkaç farklı veri kümesini düşünün me. Büyük bir masaya katılmak yerine, şimdi katılmak için daha küçük bir geçici masa var. Bu, veritabanı boyutuna bağlı olarak çok daha hızlı sorgulara neden olabilir. Sen ile aynı etkiye sahip olabilir CREATE TEMPORARY TABLE ...ve INSERT INTO ... SELECT ...çok karmaşık sorgularda daha iyi okunabilirliği sağlayabilir (ama tekrarlanabilir okuma yalıtım düzeyi veri setlerini kilitleyebilir) hangi.

Yuvalanmış alt sorgular

SELECT moo, bar
  FROM (
    SELECT moo, CONCAT(roger, wilco) AS bar
      FROM foo
      GROUP BY moo
      HAVING bar LIKE 'SpaceQ%'
  ) AS temp_foo
  ORDER BY bar

Alt sorguları birden çok düzeyde iç içe yerleştirebilirsiniz. Sonuçları gruplamanız veya sıralamanız gerekiyorsa bu, büyük veri kümelerinde yardımcı olabilir. Genellikle DB-Server bunun için geçici bir tablo oluşturur, ancak bazen tablonun tamamında, yalnızca sonuç kümesinde sıralama yapmanız gerekmez. Bu, tablonun boyutuna bağlı olarak çok daha iyi performans sağlayabilir.

Sonuç

Alt sorgular a'nın yerini tutmaz JOINve bunları böyle kullanmamalısınız (mümkünse). Benim düşünceme göre, bir alt sorgunun doğru kullanımı, hızlı bir şekilde değiştirilmesidir CREATE TEMPORARY TABLE .... İyi bir alt sorgu, bir veri kümesini a ONifadesinde başaramayacağınız şekilde azaltır JOIN. Bir alt sorgu anahtar kelimelerden birine sahipse GROUP BYveya DISTINCTtercihen select alanlarında veya where deyiminde yer almıyorsa, performansı çok artırabilir.

Her şeyden önce, ilk ikisini karşılaştırmak için sorguları alt sorgularla ayırmanız gerekir:

1. her zaman birleşimlerle yazılmış karşılık gelen eşdeğer sorguya sahip bir alt sorgu sınıfı
2. birleştirmeler kullanılarak yeniden yazılamayan bir alt sorgu sınıfı

Birinci sorgu sınıfı için iyi bir RDBMS, birleştirme ve alt sorguları eşdeğer olarak görür ve aynı sorgu planları üretir.

Bugünlerde mysql bile bunu yapıyor.

Yine de, bazen değil, ama bu her zaman kazanacak anlamına gelmez - mysql gelişmiş performans alt sorgular kullanırken vakaları vardı. (Örneğin, mysql planlayıcısının maliyeti doğru bir şekilde tahmin etmesini engelleyen bir şey varsa ve planlayıcı birleştirme varyantını ve alt sorgu varyantını aynı görmüyorsa, alt sorgular belirli bir yolu zorlayarak eklemlerden daha iyi performans gösterebilir).

Sonuç, hangisinin daha iyi performans göstereceğinden emin olmak istiyorsanız, sorgularınızı hem birleştirme hem de alt sorgu varyantları için test etmeniz gerektiğidir.

İkinci sınıf için karşılaştırma anlamlı değildir, çünkü bu sorgular birleştirmeler kullanılarak yeniden yazılamaz ve bu durumlarda alt sorgular gerekli görevleri yerine getirmenin doğal bir yoludur ve bunlara karşı ayrımcılık yapmamalısınız.

Alıntılanan cevaplarda vurgulananların , belirli (kullanım) davalardan kaynaklanabilecek kopyalar ve sorunlu sonuçlar meselesi olduğunu düşünüyorum .

(Marcelo Cantos bundan bahsetmesine rağmen)

SQL'deki Stanford Lagunita kurslarından örnek vereceğim.

Öğrenci Masası

+------+--------+------+--------+
| sID  | sName  | GPA  | sizeHS |
+------+--------+------+--------+
|  123 | Amy    |  3.9 |   1000 |
|  234 | Bob    |  3.6 |   1500 |
|  345 | Craig  |  3.5 |    500 |
|  456 | Doris  |  3.9 |   1000 |
|  567 | Edward |  2.9 |   2000 |
|  678 | Fay    |  3.8 |    200 |
|  789 | Gary   |  3.4 |    800 |
|  987 | Helen  |  3.7 |    800 |
|  876 | Irene  |  3.9 |    400 |
|  765 | Jay    |  2.9 |   1500 |
|  654 | Amy    |  3.9 |   1000 |
|  543 | Craig  |  3.4 |   2000 |
+------+--------+------+--------+

Tablo Uygula

(belirli üniversitelere ve bölümlere yapılan başvurular)

+------+----------+----------------+----------+
| sID  | cName    | major          | decision |
+------+----------+----------------+----------+
|  123 | Stanford | CS             | Y        |
|  123 | Stanford | EE             | N        |
|  123 | Berkeley | CS             | Y        |
|  123 | Cornell  | EE             | Y        |
|  234 | Berkeley | biology        | N        |
|  345 | MIT      | bioengineering | Y        |
|  345 | Cornell  | bioengineering | N        |
|  345 | Cornell  | CS             | Y        |
|  345 | Cornell  | EE             | N        |
|  678 | Stanford | history        | Y        |
|  987 | Stanford | CS             | Y        |
|  987 | Berkeley | CS             | Y        |
|  876 | Stanford | CS             | N        |
|  876 | MIT      | biology        | Y        |
|  876 | MIT      | marine biology | N        |
|  765 | Stanford | history        | Y        |
|  765 | Cornell  | history        | N        |
|  765 | Cornell  | psychology     | Y        |
|  543 | MIT      | CS             | N        |
+------+----------+----------------+----------+

Başvuran öğrencilerin GPA puanlarını bulmaya çalışalım CSAnadal programına (üniversiteye bakılmaksızın)

Bir alt sorgu kullanma:

select GPA from Student where sID in (select sID from Apply where major = 'CS');

+------+
| GPA  |
+------+
|  3.9 |
|  3.5 |
|  3.7 |
|  3.9 |
|  3.4 |
+------+

Bu sonuç kümesi için ortalama değer:

select avg(GPA) from Student where sID in (select sID from Apply where major = 'CS');

+--------------------+
| avg(GPA)           |
+--------------------+
| 3.6800000000000006 |
+--------------------+

Bir birleştirme kullanma:

select GPA from Student, Apply where Student.sID = Apply.sID and Apply.major = 'CS';

+------+
| GPA  |
+------+
|  3.9 |
|  3.9 |
|  3.5 |
|  3.7 |
|  3.7 |
|  3.9 |
|  3.4 |
+------+

bu sonuç kümesi için ortalama değer:

select avg(GPA) from Student, Apply where Student.sID = Apply.sID and Apply.major = 'CS';

+-------------------+
| avg(GPA)          |
+-------------------+
| 3.714285714285714 |
+-------------------+

İkinci denemenin, ortalama değerin hesaplanması için kopyaları saydığı göz önüne alındığında, kullanım durumumuzda yanıltıcı sonuçlar verdiği açıktır. Kullanımı olduğu da açıktır distincttabanlı açıklamada edecek - katıl ile değil o yanlışlıkla üç olaylardan birini tutacak göz önüne alındığında, sorunu ortadan 3.9skor. Doğru durum, aşağıdakilerin İKİ (2) oluşumunu hesaba katmaktır .3.9 gerçekte sahip olduğumuz puanın İKİ (2) sorgu ölçütlerimize uyan öğrencimiz olduğu .

Bazı durumlarda, bir alt sorgunun performans sorunlarının yanı sıra en güvenli yol olduğu görülmektedir.

SQL Server için MSDN Belgeleri diyor

Alt sorgular içeren birçok Transact-SQL deyimi alternatif olarak birleştirme olarak formüle edilebilir. Diğer sorular sadece alt sorgular ile sorulabilir. Transact-SQL'de, genellikle bir alt sorgu içeren bir deyim ile içermeyen anlamsal olarak eşdeğer bir sürüm arasında hiçbir performans farkı yoktur. Bununla birlikte, varoluşun kontrol edilmesi gereken bazı durumlarda, birleştirme daha iyi performans sağlar. Aksi takdirde, iç içe sorgu, dış sorgunun her bir sonucu için kopyaların ortadan kaldırılmasını sağlamak üzere işlenmelidir. Bu gibi durumlarda, birleştirme yaklaşımı daha iyi sonuçlar verir.

yani bir şeye ihtiyacınız varsa

select * from t1 where exists select * from t2 where t2.parent=t1.id

bunun yerine join kullanmayı deneyin. Diğer durumlarda, hiçbir fark yaratmaz.

Diyorum ki: Fonksiyonlar yaratmak Alt sorgular için , dağınıklık sorununu ortadan kaldırır ve alt sorgular için ek mantık uygulamasını sağlar. Bu nedenle, mümkün olduğunda alt sorgular için işlevler oluşturmanızı öneririm.

Koddaki karmaşa büyük bir sorundur ve endüstri on yıllardır bundan kaçınmak için çalışmaktadır.

Eski bir Mambo CMS'den çok büyük bir veritabanında çalıştırın:

SELECT id, alias
FROM
  mos_categories
WHERE
  id IN (
    SELECT
      DISTINCT catid
    FROM mos_content
  );

0 saniye

SELECT
  DISTINCT mos_content.catid,
  mos_categories.alias
FROM
  mos_content, mos_categories
WHERE
  mos_content.catid = mos_categories.id;

~ 3 saniye

Bir EXPLAIN, aynı sayıda satırı incelediklerini gösterir, ancak biri 3 saniye sürer ve biri anında yakındır. Hikayeden çıkarılacak ders? Performans önemliyse (ne zaman değil?), Birden fazla yol deneyin ve hangisinin en hızlı olduğunu görün.

Ve...

SELECT
  DISTINCT mos_categories.id,
  mos_categories.alias
FROM
  mos_content, mos_categories
WHERE
  mos_content.catid = mos_categories.id;

0 saniye

Yine aynı sonuçlar, aynı sayıda satır incelendi. Tahminimce DISTINCT mos_content.catid'in anlaşılması DISTINCT mos_categories.id'den çok daha uzun sürüyor.

İki vaka gibi gözlemime göre, bir tablonun 100.000'den az kaydı varsa, birleştirme hızlı çalışacaktır.

Ancak bir tablonun 100.000'den fazla kaydı olması durumunda bir alt sorgu en iyi sonuçtur.

Sorgu altında oluşturulan 500.000 kayıtları olan bir tablo var ve sonuç süresi gibi

SELECT * 
FROM crv.workorder_details wd 
inner join  crv.workorder wr on wr.workorder_id = wd.workorder_id;

Sonuç: 13.3 Saniye

select * 
from crv.workorder_details 
where workorder_id in (select workorder_id from crv.workorder)

Sonuç: 1.65 Saniye

Alt sorgular genellikle tek bir satırı atomik değer olarak döndürmek için kullanılır, ancak IN anahtar sözcüğüyle birden çok satıra karşı değerleri karşılaştırmak için kullanılabilirler. Hedef listesi, WHERE yantümcesi vb. Dahil olmak üzere bir SQL ifadesinde neredeyse tüm anlamlı noktalara izin verilir. Basit bir alt sorgu arama koşulu olarak kullanılabilir. Örneğin, bir çift tablo arasında:

   SELECT title FROM books WHERE author_id = (SELECT id FROM authors WHERE last_name = 'Bar' AND first_name = 'Foo');

Alt sorgu sonuçlarında normal değer operatörünün kullanılmasının yalnızca bir alanın döndürülmesi gerektiğini unutmayın. Diğer değerler kümesinde tek bir değerin varlığını kontrol etmekle ilgileniyorsanız IN kullanın:

   SELECT title FROM books WHERE author_id IN (SELECT id FROM authors WHERE last_name ~ '^[A-E]');

Bu, birleştirme koşulu, tablo B'de vb. Eşleşen bir kayıt bulamasa bile, A ve B tablolarından bir şeylere katılmak istediğiniz bir SOL-JOIN demekinden açıkça farklıdır.

Hız konusunda endişeleniyorsanız, veritabanınızı kontrol etmeniz ve iyi bir sorgu yazmanız ve performansta önemli bir fark olup olmadığını görmeniz gerekir.

MySQL sürümü: 5.5.28-0ubuntu0.12.04.2-log

Ayrıca JOIN'in MySQL'deki bir alt sorgudan her zaman daha iyi olduğu izlenimini edindim, ancak EXPLAIN bir karar vermenin daha iyi bir yoludur. Alt sorguların JOIN'lerden daha iyi çalıştığı bir örnek.

İşte benim 3 alt sorgu ile benim sorgu:

EXPLAIN SELECT vrl.list_id,vrl.ontology_id,vrl.position,l.name AS list_name, vrlih.position AS previous_position, vrl.moved_date 
FROM `vote-ranked-listory` vrl 
INNER JOIN lists l ON l.list_id = vrl.list_id 
INNER JOIN `vote-ranked-list-item-history` vrlih ON vrl.list_id = vrlih.list_id AND vrl.ontology_id=vrlih.ontology_id AND vrlih.type='PREVIOUS_POSITION' 
INNER JOIN list_burial_state lbs ON lbs.list_id = vrl.list_id AND lbs.burial_score < 0.5 
WHERE vrl.position <= 15 AND l.status='ACTIVE' AND l.is_public=1 AND vrl.ontology_id < 1000000000 
 AND (SELECT list_id FROM list_tag WHERE list_id=l.list_id AND tag_id=43) IS NULL 
 AND (SELECT list_id FROM list_tag WHERE list_id=l.list_id AND tag_id=55) IS NULL 
 AND (SELECT list_id FROM list_tag WHERE list_id=l.list_id AND tag_id=246403) IS NOT NULL 
ORDER BY vrl.moved_date DESC LIMIT 200;

EXPLAIN şunu gösterir:

+----+--------------------+----------+--------+-----------------------------------------------------+--------------+---------+-------------------------------------------------+------+--------------------------+
| id | select_type        | table    | type   | possible_keys                                       | key          | key_len | ref                                             | rows | Extra                    |
+----+--------------------+----------+--------+-----------------------------------------------------+--------------+---------+-------------------------------------------------+------+--------------------------+
|  1 | PRIMARY            | vrl      | index  | PRIMARY                                             | moved_date   | 8       | NULL                                            |  200 | Using where              |
|  1 | PRIMARY            | l        | eq_ref | PRIMARY,status,ispublic,idx_lookup,is_public_status | PRIMARY      | 4       | ranker.vrl.list_id                              |    1 | Using where              |
|  1 | PRIMARY            | vrlih    | eq_ref | PRIMARY                                             | PRIMARY      | 9       | ranker.vrl.list_id,ranker.vrl.ontology_id,const |    1 | Using where              |
|  1 | PRIMARY            | lbs      | eq_ref | PRIMARY,idx_list_burial_state,burial_score          | PRIMARY      | 4       | ranker.vrl.list_id                              |    1 | Using where              |
|  4 | DEPENDENT SUBQUERY | list_tag | ref    | list_tag_key,list_id,tag_id                         | list_tag_key | 9       | ranker.l.list_id,const                          |    1 | Using where; Using index |
|  3 | DEPENDENT SUBQUERY | list_tag | ref    | list_tag_key,list_id,tag_id                         | list_tag_key | 9       | ranker.l.list_id,const                          |    1 | Using where; Using index |
|  2 | DEPENDENT SUBQUERY | list_tag | ref    | list_tag_key,list_id,tag_id                         | list_tag_key | 9       | ranker.l.list_id,const                          |    1 | Using where; Using index |
+----+--------------------+----------+--------+-----------------------------------------------------+--------------+---------+-------------------------------------------------+------+--------------------------+

JOINs ile aynı sorgu:

EXPLAIN SELECT vrl.list_id,vrl.ontology_id,vrl.position,l.name AS list_name, vrlih.position AS previous_position, vrl.moved_date 
FROM `vote-ranked-listory` vrl 
INNER JOIN lists l ON l.list_id = vrl.list_id 
INNER JOIN `vote-ranked-list-item-history` vrlih ON vrl.list_id = vrlih.list_id AND vrl.ontology_id=vrlih.ontology_id AND vrlih.type='PREVIOUS_POSITION' 
INNER JOIN list_burial_state lbs ON lbs.list_id = vrl.list_id AND lbs.burial_score < 0.5 
LEFT JOIN list_tag lt1 ON lt1.list_id = vrl.list_id AND lt1.tag_id = 43 
LEFT JOIN list_tag lt2 ON lt2.list_id = vrl.list_id AND lt2.tag_id = 55 
INNER JOIN list_tag lt3 ON lt3.list_id = vrl.list_id AND lt3.tag_id = 246403 
WHERE vrl.position <= 15 AND l.status='ACTIVE' AND l.is_public=1 AND vrl.ontology_id < 1000000000 
AND lt1.list_id IS NULL AND lt2.tag_id IS NULL 
ORDER BY vrl.moved_date DESC LIMIT 200;

ve çıktı:

+----+-------------+-------+--------+-----------------------------------------------------+--------------+---------+---------------------------------------------+------+----------------------------------------------+
| id | select_type | table | type   | possible_keys                                       | key          | key_len | ref                                         | rows | Extra                                        |
+----+-------------+-------+--------+-----------------------------------------------------+--------------+---------+---------------------------------------------+------+----------------------------------------------+
|  1 | SIMPLE      | lt3   | ref    | list_tag_key,list_id,tag_id                         | tag_id       | 5       | const                                       | 2386 | Using where; Using temporary; Using filesort |
|  1 | SIMPLE      | l     | eq_ref | PRIMARY,status,ispublic,idx_lookup,is_public_status | PRIMARY      | 4       | ranker.lt3.list_id                          |    1 | Using where                                  |
|  1 | SIMPLE      | vrlih | ref    | PRIMARY                                             | PRIMARY      | 4       | ranker.lt3.list_id                          |  103 | Using where                                  |
|  1 | SIMPLE      | vrl   | ref    | PRIMARY                                             | PRIMARY      | 8       | ranker.lt3.list_id,ranker.vrlih.ontology_id |   65 | Using where                                  |
|  1 | SIMPLE      | lt1   | ref    | list_tag_key,list_id,tag_id                         | list_tag_key | 9       | ranker.lt3.list_id,const                    |    1 | Using where; Using index; Not exists         |
|  1 | SIMPLE      | lbs   | eq_ref | PRIMARY,idx_list_burial_state,burial_score          | PRIMARY      | 4       | ranker.vrl.list_id                          |    1 | Using where                                  |
|  1 | SIMPLE      | lt2   | ref    | list_tag_key,list_id,tag_id                         | list_tag_key | 9       | ranker.lt3.list_id,const                    |    1 | Using where; Using index                     |
+----+-------------+-------+--------+-----------------------------------------------------+--------------+---------+---------------------------------------------+------+----------------------------------------------+

Karşılaştırması rowsSütunun farkı söyler ve JOINs ile yapılan sorguUsing temporary; Using filesort .

Tabii ki her iki sorguyu çalıştırdığımda, ilki 0.02 saniye içinde yapılır, ikincisi 1 dakika sonra bile tamamlanmaz, bu nedenle EXPLAIN bu sorguları düzgün bir şekilde açıkladı.

list_tagTabloda INNER JOIN yoksa , yani kaldırırsam

AND (SELECT list_id FROM list_tag WHERE list_id=l.list_id AND tag_id=246403) IS NOT NULL  

ilk sorgudan ve buna göre:

INNER JOIN list_tag lt3 ON lt3.list_id = vrl.list_id AND lt3.tag_id = 246403

ikinci sorgudan sonra, EXPLAIN her iki sorgu için aynı sayıda satır döndürür ve her iki sorgu da eşit derecede hızlı çalışır.

Alt sorgular, toplama işlevlerini anında hesaplama yeteneğine sahiptir. Örneğin, kitabın minimum fiyatını bulun ve bu fiyatla satılan tüm kitapları edinin. 1) Alt Sorguları Kullanma:

SELECT titles, price
FROM Books, Orders
WHERE price = 
(SELECT MIN(price)
 FROM Orders) AND (Books.ID=Orders.ID);

2) JOIN'leri kullanma

SELECT MIN(price)
     FROM Orders;
-----------------
2.99

SELECT titles, price
FROM Books b
INNER JOIN  Orders o
ON b.ID = o.ID
WHERE o.price = 2.99;

• Genel bir kural, çoğu durumda birleşmelerin daha hızlı olmasıdır (% 99).
• Daha fazla veri tablosu varsa, alt sorgular yavaşlar.
• Veri tabloları ne kadar azsa, alt sorguların birleştirmelerle eşdeğer hızı vardır .
• Alt sorgular daha basit, anlaşılması ve okunması daha kolaydır.
• Web ve uygulama çerçevelerinin çoğu ve "ORM" leri ve "Etkin kayıt" ları alt sorgularla sorgular oluşturur , çünkü alt sorgularla sorumluluğu bölmek, kodu korumak vb.
• Daha küçük web siteleri veya uygulamalar için alt sorgular uygundur, ancak daha büyük web siteleri ve uygulamalar için , sorguda birçok alt sorgu kullanılıyorsa, özellikle sorguları birleştirmek için oluşturulan sorguları yeniden yazmanız gerekir .

Bazı insanlar "Bazı RDBMS bir yazabiliriz ki alt sorgu a katılmak ya da katılmak a alt sorgu . O bir diğerinden daha hızlı olduğunu düşündüğünde", ama bu ifade ile komplike sorguları için değil elbette, basit durumlar için geçerlidir alt sorgular hangi aslında a neden performans sorunları.

Fark sadece ikinci birleştirme tablosunun birincil tablodan önemli ölçüde daha fazla veriye sahip olması durumunda görülür. Aşağıdaki gibi bir deneyim yaşadım ...

Yüz bin girişli bir kullanıcı masamız vardı ve üyelik verileri (dostluk) yaklaşık 3 bin bin giriş vardı. Arkadaşlarınızı ve verilerini almak için birleştirme ifadesiydi, ancak büyük bir gecikmeyle. Ancak üyelik tablosunda çok az miktarda verinin bulunduğu yerlerde iyi çalışıyordu. Bir alt sorgu kullanmak için değiştirdikten sonra iyi çalıştı.

Ancak bu arada birleştirme sorguları birincil tablodan daha az girdiye sahip diğer tablolarla çalışır.

Bu yüzden katılmak ve alt sorgu deyimleri iyi çalışıyor ve veri ve duruma bağlıdır düşünüyorum.

Bu günlerde, birçok dbs alt sorguları ve birleştirmeleri optimize edebilir. Böylece, sorgunuzu açıklamak ve hangisinin daha hızlı olduğunu görmek için incelemeniz yeterlidir. Performansta çok fazla fark yoksa, basit ve anlaşılması daha kolay oldukları için alt sorguyu kullanmayı tercih ederim.

Ben sadece aynı sorunu düşünüyorum, ama FROM bölümünde alt sorgu kullanıyorum. Bağlanmak ve büyük tablolardan sorgu gerekir, "köle" tablo 28 milyon kayıt var ama sonuç sadece 128 kadar küçük sonuç büyük veri! Üzerinde MAX () işlevi kullanıyorum.

İlk önce LEFT JOIN kullanıyorum çünkü doğru yol olduğunu düşünüyorum, mysql en iyi duruma getirebilir vs.

SOLA KATIL çalışma zamanı: 1.12s SUB-SELECT çalışma zamanı: 0.06s

Alt seçime katılmaktan 18 kat daha hızlı! Sadece chokito'da Alt seçim korkunç görünüyor ama sonuç ...

Join kullanarak sorgunuzu hızlandırmak istiyorsanız:

"İç birleşim / birleşim" için, "ON" koşulunda kullanmayın. Örneğin:

     select id,name from table1 a  
   join table2 b on a.name=b.name
   where id='123'

 Try,

    select id,name from table1 a  
   join table2 b on a.name=b.name and a.id='123'

"Sol / Sağ Birleştirme" için, "ON" koşulunda kullanmayın, çünkü sol / sağ birleştirme kullanırsanız, herhangi bir tablo için tüm satırları alır. Bu nedenle, "Nerede" koşulunu kullanmaya çalışın