SELECT * neden zararlı kabul edilir?

Neden SELECT *kötü uygulama? İstediğiniz yeni bir sütun eklediyseniz değiştirmek daha az kod anlamına gelmez mi?

SELECT COUNT(*)Bazı DB'lerde bir performans sorunu olduğunu anlıyorum , ama ya gerçekten her sütunu isteseydiniz?

Gerçekten üç önemli neden var:

• Verileri tüketiciye taşımada verimsizlik. SELECT * seçtiğinizde, veritabanınızdan genellikle uygulamanızın gerçekten çalışması gerekenden daha fazla sütun alırsınız. Bu, veritabanı sunucusundan istemciye daha fazla verinin taşınmasına, makinelerinize erişimi yavaşlatmaya ve yükün artmasına neden olurken, ağ üzerinden seyahat etmek için daha fazla zaman alır. Bu, özellikle, var olmayan tablolara yeni sütunlar eklediğinde ve orijinal tüketiciler veri erişimini kodladığında gerekli olmayan yeni sütunlar eklediğinde geçerlidir.

• Endeksleme sorunları. Bir sorguyu yüksek performans düzeyine ayarlamak istediğiniz bir senaryo düşünün. * Kullanacaksanız ve gerçekten ihtiyaç duyduğunuzdan daha fazla sütun döndürdüyse, sunucunun verilerinizi almak için genellikle diğerlerinden daha pahalı yöntemler kullanması gerekir. Örneğin, SELECT listenizdeki sütunları kapsayan bir dizin oluşturamazsınız ve (tüm sütunlar dahil [ shudder ]), gelip alttaki sütuna sütun ekleyen bir sonraki kişi bile tablosu, optimize edicinin optimize edilmiş kaplama dizininizi yok saymasına neden olur ve sorgunuzun performansının, kolayca görünen bir nedenden ötürü önemli ölçüde düşeceğini fark edersiniz.

• Ciltleme Sorunları. SEÇ * 'i seçtiğinizde, aynı addaki iki sütunu iki farklı tablodan almak mümkündür. Bu genellikle veri tüketicinizi çökertebilir. Her ikisi de "ID" adlı bir sütun içeren iki tabloyu birleştiren bir sorgu düşünün. Tüketici hangisinin hangisi olduğunu nasıl bilebilir? SELECT *, temel tablo yapıları değiştiğinde görünümleri (en azından bazı SQL Server sürümlerinde) karıştırabilir - görünüm yeniden oluşturulmaz ve geri gelen veriler saçma olabilir . Ve en kötü yanı, sütunlarınızı ne istersen adlandırmaya dikkat edebilmenizdir, ancak gelen bir sonraki adam, zaten gelişmiş olanınızla çarpışacak bir sütun eklemek konusunda endişelenmesi gerektiğini bilmenin bir yolu olmayabilir. isimler.

Ancak SELECT * için hepsi kötü değil. Bu kullanım örnekleri için liberal olarak kullanıyorum:

• Geçici sorgular. Bir şeyde hata ayıklamaya çalışırken, özellikle aşina olamayacağım dar bir masada, SELECT * genellikle en iyi arkadaşımdır. Altta yatan sütun adlarının ne olduğu konusunda bir sürü araştırma yapmak zorunda kalmadan neler olup bittiğini görmeme yardımcı oluyor. Bu, sütun adları ne kadar uzun olursa, daha büyük bir "artı" olur.

• * "Satır" anlamına geldiğinde. Aşağıdaki kullanım örneklerinde SELECT * gayet iyi ve performans katili olduğu söylentileri sadece yıllar önce bazı geçerliliği olan kentsel efsanelerdir, ancak şimdi yok:

  SELECT COUNT(*) FROM table;

  bu durumda *, "satırları say" anlamına gelir. * Yerine bir sütun adı kullanırsanız, bu sütunun değerinin boş olmadığı satırları sayar . COUNT (*), bana gerçekten, satırları saydığınız kavramı yönlendiriyor ve NULL'ların kümelerinizden kaldırılmasına neden olan garip kenar durumlarından kaçınıyorsunuz.

  Bu tür bir sorgu için de aynı şey geçerlidir:

  SELECT a.ID FROM TableA a
  WHERE EXISTS (
      SELECT *
      FROM TableB b
      WHERE b.ID = a.B_ID);

  tuz değerinde herhangi bir veritabanında * sadece "satır" anlamına gelir. Alt sorguya ne koyduğunuz önemli değil. Bazı insanlar SELECT listesinde b'nin kimliğini kullanırlar ya da 1 sayısını kullanırlar, ancak IMO bu sözleşmeler neredeyse saçmadır. Demek istediğin "satırı say" ve bu * anlamına gelir. Çoğu sorgu optimize edici bunu bilmek için yeterince akıllı. (Dürüst olmak gerekirse, bunun sadece SQL Server ve Oracle ile doğru olduğunu biliyorum .)

SELECT deyimindeki yıldız işareti "*", sorguda yer alan tablo (lar) daki tüm sütunlar için kısaltmadır.

Verim

*Stenografi olabilir yavaş çünkü:

• Tüm alanlar endekslenmez, tam tablo taramasını zorlar - daha az verimli
• SELECT *Kablo üzerinden göndermek için kaydettikleriniz tam masa taraması riskiyle karşı karşıya
• Gerekenden daha fazla veri döndürme
• Değişken uzunluktaki veri türünü kullanarak sondaki sütunları döndürmek arama ek yüküne neden olabilir

Bakım

Kullanırken SELECT *:

• Kod tabanına aşina olmayan biri, yetkili değişiklikler yapmadan önce hangi sütunların döndürüldüğünü bilmek için belgelere başvurmak zorunda kalır. Kodu daha okunabilir hale getirmek, kodu bilmeyen insanlar için gerekli belirsizliği ve işi en aza indirmek, uzun vadede daha fazla zaman ve çaba tasarrufu sağlar.
• Kod sütun sırasına bağlıysa, SELECT * bağlıysa, bir tablonun sütun sırası değiştiyse gerçekleşmesini bekleyen bir hatayı gizler.
• Sorgu yazıldığı sırada her sütuna ihtiyacınız olsa bile, gelecekte durum böyle olmayabilir
• kullanım profili oluşturmayı zorlaştırır

tasarlamak

SELECT *bir anti-desendir :

• Sorgunun amacı daha az belirgindir; uygulama tarafından kullanılan sütunlar opaktır
• Mümkün olduğunca katı yazım kullanma hakkındaki modülerlik kuralını ihlal eder. Açık neredeyse evrensel olarak daha iyidir.

"SELECT *" Ne Zaman Kullanılmalı?

SELECT *Sorgu yazıldığında var olan her sütunun aksine, tablolardaki her sütun için açık bir gereksinim olduğunda kullanılması kabul edilebilir . Veritabanı dahili olarak * sütunların tam listesine genişler - performans farkı yoktur.

Aksi takdirde, sorguda kullanılacak her sütunu açıkça belirtin - tercihen bir tablo diğer adı kullanırken.

Şimdi her sütunu seçmek isteseniz bile, birisi bir veya daha fazla yeni sütun ekledikten sonra her sütunu seçmek istemeyebilirsiniz. Sorguyu sizinle yazarsanız, bir SELECT *noktada, o sütuna gerçekten ihtiyacınız olmasa bile, sorgunuzun daha yavaş çalışmasını sağlayan bir metin sütunu ekleyebileceği riskini alırsınız.

İstediğiniz yeni bir sütun eklediyseniz değiştirmek daha az kod anlamına gelmez mi?

Şansınız, yeni sütunu gerçekten kullanmak istiyorsanız, yine de kodunuzda çok daha fazla değişiklik yapmanız gerekecek olmasıdır. Sadece tasarruf edersiniz , new_column- sadece birkaç karakter yazarak.

Sütunları SELECT deyiminde adlandırırsanız, sütunlar belirtilen sırayla döndürülür ve bu nedenle sayısal dizin tarafından güvenli bir şekilde başvurulabilir. "SELECT *" kullanırsanız, sütunları rasgele sırayla alabilir ve böylece sütunları yalnızca ada göre güvenli bir şekilde kullanabilirsiniz. Veritabanına eklenen yeni sütunlarla ne yapmak isteyeceğinizi önceden bilmediğiniz sürece, en olası doğru eylem onu ​​yok saymaktır. Veritabanına eklenen yeni sütunları yok sayacaksanız, bunları almanın hiçbir faydası yoktur.

Birçok durumda SELECT *, tasarım zamanında değil, uygulamanızda çalışma zamanında hatalara neden olur. Sütun değişiklikleri bilgisini veya uygulamalarınızdaki hatalı referansları gizler.

Gerçekten her sütunu istiyorsanız, select (*) ile sütunları adlandırma arasında bir performans farkı görmedim. Sütunları adlandıracak sürücü, kodunuzda görmeyi beklediğiniz sütunlar hakkında açık olabilir.

Yine de, her sütunu istemezsiniz ve select (*) veritabanı sunucusu için gereksiz çalışmaya ve gereksiz bilgilerin ağ üzerinden geçirilmesine neden olabilir. Sistem çok kullanılmadığı veya ağ bağlantısı yavaş olmadığı sürece fark edilir bir soruna neden olması olası değildir.

Bunu, uygulama ve veritabanı arasındaki bağlantıyı azaltmak olarak düşünün.

'Kod kokusu' yönünü özetlemek gerekirse:
SELECT *uygulama ve şema arasında dinamik bir bağımlılık yaratır. Kullanımını kısıtlamak, bağımlılığı daha tanımlanmış hale getirmenin bir yoludur, aksi takdirde veritabanında yapılan bir değişiklik, uygulamanızın çökmesine neden olabilir.

Tabloya alanlar eklerseniz, bunlar kullandığınız tüm sorgularınıza otomatik olarak dahil edilir select * . Bu kullanışlı görünebilir, ancak ihtiyacınız olandan daha fazla veri alırken uygulamanızı yavaşlatacaktır ve aslında bir noktada uygulamanızı kilitleyecektir.

Bir sonucun her satırında ne kadar veri alabileceğiniz konusunda bir sınır vardır. Sonuçların bu sınırın üzerine çıkması için tablolarınıza alanlar eklerseniz, sorguyu çalıştırmayı denediğinizde bir hata iletisi alırsınız.

Bu, bulunması zor hatalardır. Bir yerde bir değişiklik yaparsınız ve yeni verileri gerçekten kullanmayan başka bir yerde patlar. Daha az kullanılan bir sorgu bile olabilir, böylece birisinin kullanması biraz zaman alır, bu da hatayı değişikliğe bağlamayı daha da zorlaştırır.

Sonuçta hangi alanları istediğinizi belirtirseniz, bu tür havai taşmaya karşı güvende olursunuz.

Bu makaleden referans alınmıştır.

Asla "SELECT *" ile gitmeyin,

"SELECT *" kullanmak için yalnızca bir neden buldum

Özel gereksinimleriniz varsa ve sütun eklerken veya silerken dinamik bir ortam oluşturduysanız, uygulama koduyla otomatik olarak işlenir. Bu özel durumda uygulama ve veritabanı kodunu değiştirmeniz gerekmez ve bu otomatik olarak üretim ortamını etkileyecektir. Bu durumda “SELECT *” kullanabilirsiniz.

Genelde sonuçlarınızı SELECT * ...çeşitli tiplerdeki veri yapılarına sığdırmanız gerekir . Sonuçların hangi sırayla geldiğini belirtmeden, her şeyi doğru bir şekilde sıralamak zor olabilir (ve daha belirsiz alanların kaçırılması çok daha kolaydır).

Bu şekilde, çeşitli nedenlerden ötürü tüm uygulamalarda sql erişim kodunu kırmadan tablolarınıza (bunların ortasında bile) alanlar ekleyebilirsiniz.

SELECT *Yalnızca birkaç sütuna ihtiyacınız olduğunda kullanmak , ihtiyacınız olandan çok daha fazla veri aktarılması anlamına gelir. Bu, veritabanına işlem ekler ve verileri istemciye alma gecikmesini artırır. Buna yüklendiğinde daha fazla bellek kullanacağını, bazı durumlarda büyük BLOB dosyaları gibi daha fazla bellek kullanacağını, çoğunlukla verimlilikle ilgili olduğunu ekleyin.

Buna ek olarak, sorguya bakarken tabloda hangi sütunların olduğuna bakmak zorunda kalmadan hangi sütunların yüklendiğini görmek daha kolaydır.

Evet, fazladan bir sütun eklerseniz, daha hızlı olur, ancak çoğu durumda, yeni sütunları yine de kabul etmek için sorguyu kullanarak kodunuzu değiştirmek istersiniz / yapmanız gerekir ve yapmadığınız sütunları alma potansiyeli vardır ' t İstiyorum / beklemek sorunlara neden olabilir. Örneğin, tüm sütunları alırsanız, değişkenleri atamak için bir döngüdeki sıraya güvenirseniz, sonra bir tane ekler veya sütun siparişleri değişirse (bir yedeklemeden geri yüklerken görüldüğünde) her şeyi atabilir.

Bu, aynı zamanda, bir INSERTsütun kullanıyorsanız, her zaman sütunları belirtmeniz gerektiğinin de aynı nedenidir .

Bunun için gerçekten bir battaniye kuralı olabileceğini sanmıyorum. Birçok durumda SELECT * 'den kaçındım, ancak SELECT *' in çok faydalı olduğu veri çerçeveleri ile de çalıştım.

Her şeyde olduğu gibi, faydalar ve maliyetler vardır. Fayda ile maliyet denkleminin bir kısmının veri yapıları üzerinde ne kadar kontrolünüz olduğunu düşünüyorum. SELECT * 'in iyi çalıştığı durumlarda, veri yapıları sıkı bir şekilde kontrol edildi (perakende yazılımdı), bu yüzden birisinin büyük bir BLOB alanını bir masaya yaslama riski pek yoktu.

Sütun adıyla seçim yapmak, veritabanı motorunun tablo verilerini sorgulamak yerine dizinlerden verilere erişme olasılığını artırır.

SELECT *, kodunuz bu yeni verileri kullanmaya veya sunmaya hazır olmasa da, tabloya yeni sütunlar ekleyeceğiniz için veritabanı şemanızın değişmesi durumunda sisteminizi beklenmedik performans ve işlevsellik değişikliklerine maruz bırakır.

Daha pragmatik bir neden de var: para. Bulut veritabanını kullandığınızda ve işlenen veriler için ödeme yapmanız gerektiğinde, hemen atacağınız verileri okumak için bir açıklama yoktur.

Örneğin: BigQuery :

Sorgu fiyatlandırması

Sorgu fiyatlandırması, SQL komutlarınızı ve kullanıcı tanımlı işlevleri çalıştırmanın maliyetini ifade eder. BigQuery bir metrik kullanarak sorgular için ücret alır: işlenen bayt sayısı.

ve Kontrol projeksiyonu - SELECT * 'den kaçının :

En iyi yöntem: Kontrol projeksiyonu - Yalnızca ihtiyacınız olan sütunları sorgulayın.

Yansıtma, sorgunuz tarafından okunan sütun sayısını ifade eder. Fazla sütunların yansıtılması ek (israf) G / Ç ve materyalizasyon (sonuç yazma) gerektirir.

SELECT * kullanmak verileri sorgulamanın en pahalı yoludur. SELECT * kullandığınızda, BigQuery tablodaki her sütunun tam taramasını yapar.

Şemayı tasarlamadan önce gereksinimlerinizi anlayın (mümkünse).

Veriler hakkında bilgi edinin, 1) indeksleme 2) kullanılan depolama türü, 3) satıcı motoru veya özellikleri; yani ... önbellekleme, bellek içi yetenekler 4) veri türleri 5) tablo boyutu 6) sorgulama sıklığı 7) kaynak paylaşılıyorsa ilgili iş yükleri 8) Test

A) Gereksinimler değişiklik gösterecektir. Donanım beklenen iş yükünü destekleyemiyorsa, iş yükündeki gereksinimlerin nasıl sağlanacağını yeniden değerlendirmelisiniz. Tabloya ekleme sütunu ile ilgili. Veritabanı görünümleri destekliyorsa, adlandırılmış sütunlarla belirli verilerin dizine alınmış (?) Bir görünümünü oluşturabilirsiniz (vs. '*' öğesini seçin). "Garbage-in" -> "Garbage-out" sendromuna asla girmediğinizden emin olmak için verilerinizi ve şemanızı düzenli olarak gözden geçirin.

Başka bir çözüm olmadığını varsayarsak; aşağıdakileri dikkate alabilirsiniz. Bir soruna her zaman birden fazla çözüm vardır.

1) Dizin oluşturma: Select * bir tablo taraması gerçekleştirir. Çeşitli faktörlere bağlı olarak, bu, bir disk araması ve / veya diğer sorgularla çekişmeyi içerebilir. Tablo çok amaçlıysa, tüm sorguların performans gösterdiğinden ve hedef sürelerinizin altında yürütüldüğünden emin olun. Çok miktarda veri varsa ve ağınız veya diğer kaynak ayarlanmamışsa; bunu dikkate almanız gerekir. Veritabanı paylaşılan bir ortamdır.

2) depolama türü. Yani: SSD, disk veya bellek kullanıyorsanız. G / Ç süreleri ve sistem / işlemci üzerindeki yük değişecektir.

3) DBA veritabanını / tabloları daha yüksek performans için ayarlayabilir mi? Her ne sebeple olursa olsun, takımlar '*' seçiminin soruna en iyi çözüm olduğuna karar verdiler; DB veya tablo belleğe yüklenebilir. (Ya da başka bir yöntem ... belki de cevap 2-3 saniyelik bir gecikmeyle cevap verecek şekilde tasarlandı?

4) Başlangıçta başlayın. Veri türlerinizi ve sonuçların nasıl sunulacağını öğrenin. Daha küçük veri tipleri, alan sayısı sonuç kümesinde döndürülen veri miktarını azaltır. Bu, kaynakları diğer sistem ihtiyaçları için kullanılabilir halde bırakır. Sistem kaynakları genellikle bir sınıra sahiptir; 'daima' istikrar ve öngörülebilir davranış sağlamak için bu sınırların altında çalışır.

5) tablo / veri boyutu. '*' seçeneğini seçmek küçük tablolarda yaygındır. Genellikle belleğe sığarlar ve yanıt süreleri hızlıdır. Tekrar .... ihtiyaçlarınızı gözden geçirin. Özellik sürünme planı; daima mevcut ve gelecekteki olası ihtiyaçları planlayın.

6) Sorgu / sorgu sıklığı. Sistemdeki diğer iş yüklerinin farkında olun. Bu sorgu her saniye tetiklenirse ve tablo küçükse. Sonuç kümesi önbellekte / bellekte kalacak şekilde tasarlanabilir. Ancak, sorgu Gigabytes / Terabytes veri ile sık bir toplu işlemse ... diğer iş yüklerinin etkilenmemesini sağlamak için ek kaynaklar ayırmak daha iyi olabilir.

7) İlgili iş yükleri. Kaynakların nasıl kullanıldığını anlayın. Ağ / sistem / veritabanı / tablo / uygulama adanmış veya paylaşılmış mı? Paydaşlar kimlerdir? Bu üretim, geliştirme veya KG için mi? Bu geçici bir "hızlı düzeltme" midir. Senaryoyu test ettiniz mi? Bugün mevcut donanımda kaç sorun olabileceğine şaşıracaksınız. (Evet, performans hızlıdır ... ancak tasarım / performans hala düşüktür.) Sistemin saniyede 10 bin sorgu yerine saniyede 5-10 sorgu gerçekleştirmesi gerekiyor mu? Veritabanı sunucusu adanmış mı yoksa başka uygulamalar mı yapıyor, paylaşılan kaynakta izleme yürütülüyor mu? Bazı uygulamalar / diller; O / S, çeşitli semptomlara / sorunlara neden olarak belleğin% 100'ünü tüketecektir.

8) Test: Teorilerinizi test edin ve olabildiğince çok anlayın. Seçtiğiniz '*' sorununuz önemli olabilir veya endişelenmenize gerek bile olmayan bir şey olabilir.