Farklı şirketler için çalışıyorum ve bazılarının tüm "akrabaları" ile bir masaya katılacak görüşlere sahip olmayı tercih ettiklerini fark ettim. Ancak daha sonra uygulamada bazı zamanlar sadece 1 sütun kullanmamız gerekir.

Öyleyse basit seçimler yapmak daha hızlı olur mu ve sonra sistem kodunda onlara "katılın" mı?

Sistem php, java, asp, veritabanına bağlanan herhangi bir dil olabilir.

Öyleyse asıl soru, bir Sunucu Tarafından (php, java, asp, ruby, python ...) veritabanına hızlı giden şey, ihtiyacımız olan her şeyi alan sunucudan veritabanına giden bir sorguyu çalıştırmak ve sadece bir tablodan sütunları alan sorgu?

Sorunuza cevap verecek konu JOIN DECOMPOSITION.

Kitabın 209. Sayfasına Göre

Çok birleşimli birleştirme yerine birden çok tekli tablo sorgusu çalıştırarak ve ardından uygulamadaki birleştirme işlemini gerçekleştirerek bir birleşimi ayrıştırabilirsiniz. Örneğin, bu tek sorgu yerine:

SELECT * FROM tag
JOIN tag_post ON tag_post.tag_id = tag.id
JOIN post ON tag_post.post_id = post.id
WHERE tag.tag = 'mysql';

Bu sorguları çalıştırabilirsiniz:

SELECT * FROM tag WHERE tag = 'mysql';
SELECT * FROM tag_post WHERE tag_id=1234;
SELECT * FROM post WHERE post.id IN (123,456,567,9098,8904);

Neden bunu dünyada yapıyorsun? İlk bakışta savurgan görünüyor, çünkü karşılığında hiçbir şey almadan sorgu sayısını arttırdınız. Bununla birlikte, böyle bir yeniden yapılandırma aslında önemli performans avantajları sağlayabilir:

• Önbellekleme daha verimli olabilir. Birçok uygulama, doğrudan tablolarla eşleşen "nesneleri" önbelleğe alır. Bu örnekte, etiketli nesne mysqlzaten önbelleğe alınmışsa , uygulama ilk sorguyu atlayacaktır. Önbellekte 123, 567 veya 908 kimliği olan gönderiler bulursanız, bunları IN()listeden kaldırabilirsiniz . Sorgu önbelleği de bu stratejiden yararlanabilir. Tablolardan yalnızca bir tanesi sık sık değişirse, bir birleşimin ayrıştırılması, önbellek geçersiz kılma sayısını azaltabilir.
• Sorguları tek tek yürütmek bazen kilit sürekliliğini azaltabilir
• Uygulamaya katılma işlemleri, farklı sunuculara tablolar yerleştirerek veritabanını ölçeklendirmeyi kolaylaştırır.
• Sorguların kendileri daha verimli olabilir. Bu örnekte, IN()bir birleştirme yerine bir listenin kullanılması, MySQL'in sıra kimliklerini sıralamasına ve bir birleşimde mümkün olabileceğinden daha iyi bir şekilde satırları almasına izin verir.
• Gereksiz satır erişimlerini azaltabilirsiniz. Uygulamada bir birleştirme yapmak, her satırı yalnızca bir kez almak anlamına gelir, oysa sorgudaki bir birleşme, esasen aynı verilere tekrar tekrar erişebilecek bir denormalizasyondur. Aynı nedenden ötürü, böyle bir yeniden yapılandırma toplam ağ trafiğini ve bellek kullanımını da azaltabilir.
• Bir dereceye kadar, bu tekniği iç içe geçmiş döngü algoritması yerine bir karma birleşimini el ile uygulamak olarak görebilirsiniz, MySQL bir birleşim yürütmek için kullanır. Bir karma katılım daha verimli olabilir.

Sonuç olarak, daha önce yapılan sorgulardan çok fazla veri önbelleğe aldığınızda ve bunları yeniden kullandığınızda, birden çok sunucuya veri dağıtırken, birleştirme işlemlerini IN()listelerle değiştirdiğinizde veya bir birleştirme aynı tabloya birden çok defa başvurduğunda, uygulamadaki katılımlar daha verimli olabilir .

GÖZLEM

İlk madde işaretini seviyorum, çünkü InnoDB sorgu önbelleğini geçtiğinde biraz el aldı.

• Sep 05, 2012: Sık sık sorgu önbellek geçersiz kılma yükü buna değdi mi?
• Jun 07, 2014: Neden query_cache_type MySQL 5.6'dan varsayılan başlatmayı devre dışı bıraktı?

Son madde işaretine gelince, iç içe geçmiş döngü algoritmasını tanımlayan 11 Mart 2013 tarihinde bir JOIN koşulu ve bir WHERE koşulu arasında bir yürütme farkı var mı? ). Okuduktan sonra, birleşme bozulmasının ne kadar iyi olabileceğini göreceksiniz.

Kitaptaki diğer tüm noktalara gelince , geliştiriciler gerçekten performans olarak alt satırda görünüyor. Bazıları, hızlı disk kullanma, daha fazla CPU / Çekirdek alma, depolama motorunu ayarlama ve yapılandırma dosyasını ayarlama gibi performans geliştirmeleri için harici araçlara (uygulamanın dışında) güveniyor. Diğerleri çökertecek ve daha iyi kod yazacak. Bazıları Saklı Prosedürlerde tüm iş zekasını kodlamaya başvurabilir, ancak birleşik ayrıştırma uygulayamazlar (Bkz . Diğer mantıklarla birlikte uygulama mantığını veritabanı katmanına koymanın veya bunun için ne gibi argümanlar var? ). Her şey, her geliştirici dükkanının kültürüne ve toleransına bağlı.

Bazıları performanstan memnun olabilir ve artık koda dokunmuyor olabilir. Diğerleri basitçe, kompozisyona katılmaya çalışırlarsa elde edebileceğin büyük faydalar olduğunun farkında değilsin.

İstekli geliştiriciler için ...

BİR ŞANS VER !!!

In Postgres (ve muhtemelen benzer bir ölçüde herhangi RDBMS, bir dereceye kadar MySQL), daha az sorguları neredeyse her zaman çok daha hızlı.

Birden çok sorguyu ayrıştırma ve planlama ek yükü, çoğu durumda zaten olası herhangi bir kazancından daha fazladır.

Müşteride yapılacak ek işlerden bahsetmemek, genellikle bu konuda çok daha yavaş olan sonuçları birleştirmek . Bir RDBMS bu tür görevlerde uzmanlaşmıştır ve işlemler orijinal veri türlerine dayanmaktadır. textAra sonuçlar için geri dönüş veya geri dönüş yok veya müşterinin doğal türüne dönüşüyor, bu da daha az doğru (veya yanlış!) Sonuçlara yol açabiliyor. Kayan nokta sayılarını düşünün ...

Ayrıca, DB sunucusu ve istemci arasında daha fazla veri aktarın. Bu, değerlerle dolu bir el için önemsiz olabilir veya çok büyük bir fark yaratabilir.

Birden fazla sorgu, veritabanı sunucusuna çok sayıda tur atılması anlamına geliyorsa, ağ gecikmesinin ve işlem ek yükünün, muhtemelen ek yük bağlantısının birkaç katı toplarsınız. Büyük, büyük kayıp.

Kurulumunuza bağlı olarak, yalnızca ağ gecikmesi büyüklük sırasına göre diğerlerinden daha uzun sürebilir.

SO ile ilgili soru:

• Hangisi daha iyi? Sql veya uygulamanızda hesaplamaları yapma

Çok büyük , uzun süre çalışan sorgular için bir dönüm noktası olabilir , çünkü işlemler yolda DB satırlarında kilitler toplar. Çok büyük sorgular, uzun süre boyunca birçok kilit tutabilir ve bu da eşzamanlı sorgular ile sürtünmeye neden olabilir .