seçme * ile sütun seçme

Sadece 2/3 sütuna ihtiyacım olursa ve sorgularım SELECT * bu sütunları seçme sorgusunda sağlamak yerine , daha fazla / daha az G / Ç veya bellekle ilgili herhangi bir performans düşüşü olur mu?

* Gerek kalmadan seçersem ağ ek yükü mevcut olabilir.

Ancak belirli bir işlemde, veritabanı motoru her zaman diskten atomik tuple mı çekiyor yoksa yalnızca seçme işleminde istenen sütunları mı çekiyor?

Her zaman bir demet çekiyorsa, G / Ç ek yükü aynıdır.

Aynı zamanda, bir demet çekerse, istenen sütunları tuple'dan çıkarmak için bir bellek tüketimi olabilir.

Öyleyse, durum buysa, someColumn'un seçilenden daha fazla bellek ek yüküne sahip olacağını seçin *

Her zaman bir demet çeker (tablonun dikey olarak bölümlere ayrıldığı - sütun parçalarına bölündüğü durumlar hariç), bu nedenle sorduğunuz soruyu yanıtlamak performans açısından önemli değildir. Bununla birlikte, diğer birçok nedenden dolayı (aşağıda), her zaman özellikle istediğiniz sütunları ada göre seçmelisiniz.

Her zaman bir demet çeker, çünkü (aşina olduğum her satıcı RDBMS'de), her şeyin temelindeki disk üstü depolama yapısı (tablo verileri dahil), tanımlanmış G / Ç Sayfalarına dayanır (örneğin, SQL Server'da, her Sayfa 8 kilobayt). Ve her G / Ç okuma veya yazma Sayfa'ya göre .. Yani, her yazma veya okuma eksiksiz bir veri Sayfasıdır.

Bu temel yapısal kısıtlama nedeniyle, bir sonuç olarak, bir veritabanındaki her veri satırı her zaman bir ve yalnızca bir sayfada olmalıdır. Birden fazla veri Sayfasına yayılamaz (gerçek blob verilerinin ayrı Sayfa yığınlarında depolandığı ve gerçek tablo satırı sütununun daha sonra yalnızca bir işaretçi aldığı bloblar gibi özel şeyler hariç). Ancak bu istisnalar sadece istisnalardır ve özel durumlar haricinde genellikle geçerli değildir (özel veri türleri veya özel durumlar için belirli optimizasyonlar)
Bu özel durumlarda bile, genellikle, verilerin gerçek tablo satırının kendisi ( Blob için gerçek verilere işaretçi veya her neyse), tek bir GÇ Sayfasında depolanmalıdır ...

İSTİSNA. Uygun olduğu tek yer Select *, aşağıdaki gibi bir Existsveya Not Existsyüklem cümlesinden sonraki alt sorgudadır:

   Select colA, colB
   From table1 t1
   Where Exists (Select * From Table2
                 Where column = t1.colA)

DÜZENLEME: @Mike Sherer yorumuna hitap etmek için, Evet, hem teknik olarak, hem özel durumunuz için hem de estetik olarak biraz tanımla doğrudur. İlk olarak, istenen sütun kümesi bazı dizinde depolananların bir alt kümesi olsa bile, sorgu işlemcisi aynı nedenlerle yalnızca istenenleri değil, o dizinde depolanan her sütunu getirmelidir - TÜM G / Ç, sayfalar ve dizin verileri, tablo verileri gibi IO Sayfalarında saklanır. Dolayısıyla, bir dizin sayfası için "tuple" ı dizinde depolanan sütun kümesi olarak tanımlarsanız, ifade yine de doğrudur.
ve ifade estetik olarak doğrudur çünkü asıl mesele, verileri istediğiniz şeye değil, G / Ç sayfasında depolananlara göre getirmesidir ve bu, temel tablo G / Ç Sayfasına veya bir dizine erişiyor olsanız da geçerlidir. I / O Sayfası.

Kullanmamak için diğer nedenler için Select *bkz. Neden SELECT *zararlı kabul edilir? :

SELECT *Üretim kodunda asla (asla) kullanmamanızın birkaç nedeni vardır :

• Veritabanınıza ne istediğinize dair herhangi bir ipucu vermediğiniz için, o tablodaki sütunları belirlemek için önce tablonun tanımını kontrol etmesi gerekecektir. Bu arama biraz zamana mal olacak - tek bir sorguda çok fazla değil - ama zamanla artıyor

• sütunların yalnızca 2 / 3'üne ihtiyacınız varsa, 1 / 3'ünde çok fazla veri seçiyorsunuz, bu da diskten alınması ve ağ üzerinden gönderilmesi gerekiyor

• Verinin belirli yönlerine güvenmeye başlarsanız, örneğin döndürülen sütunların sırası, tablo yeniden düzenlendikten ve yeni sütunlar eklendiğinde (veya var olanlar kaldırıldığında) kötü bir sürprizle karşılaşabilirsiniz.

• SQL Server'da (diğer veritabanları hakkında emin değil), bir sütun alt kümesine ihtiyacınız varsa, her zaman kümelenmemiş bir dizinin bu isteği karşılama ihtimali vardır (gerekli tüm sütunları içerir). A ile SELECT *, bu olasılıktan en başından vazgeçiyorsunuz. Bu özel durumda, veriler dizin sayfalarından (eğer bunlar gerekli tüm sütunları içeriyorsa) alınır ve dolayısıyla disk G / Ç ve bellek ek yükü, bir SELECT *....sorgu yapmaya kıyasla çok daha az olur .

Evet, başlangıçta biraz daha fazla yazmayı gerektirir ( SQL Server için SQL İstemi gibi araçlar size yardımcı olacaktır) - ancak bu gerçekten istisnasız bir kuralın olduğu bir durumdur: üretim kodunuzda asla SELECT * kullanmayın. HİÇ.

Her zaman yalnızca selectgerçekten ihtiyacınız olan sütunları kullanmalısınız. Daha çok yerine daha azını seçmek hiçbir zaman daha az verimli değildir ve ayrıca daha az beklenmedik yan etkiyle karşılaşırsınız - örneğin, istemci tarafında sonuç sütunlarınıza indeksle erişmek, ardından tabloya yeni bir sütun ekleyerek bu dizinlerin yanlış hale gelmesini sağlamak gibi.

[değiştir]: Erişim anlamına geliyor. Aptal beyin hala uyanıyor.

Büyük lekeler depolamadığınız sürece performans bir sorun teşkil etmez. SELECT * 'i kullanmamanın en büyük nedeni, döndürülen satırları tuple olarak kullanıyorsanız, sütunların şemanın belirttiği sırayla geri gelmesi ve bu değişirse tüm kodunuzu düzeltmeniz gerekmesidir.

Öte yandan, sözlük tarzı erişim kullanıyorsanız, sütunların hangi sırayla geldiği önemli değildir çünkü onlara her zaman adıyla erişiyorsunuz.

Bu hemen aklıma kullandığım bir sütun türü içeren bir tablo getiriyor blob; genellikle birkaç Mbs boyutunda bir JPEG resmi içeriyordu .

Söylemeye gerek yok, gerçekten ihtiyacım SELECTolmadıkça o köşeyi yapmadım . Bu verilerin etrafta dolaşması - özellikle birden çok satır seçtiğimde - sadece bir güçlüktü.

Ancak, normalde bir tablodaki tüm sütunları sorguladığımı itiraf edeceğim.

Bir SQL seçimi sırasında, DB SELECT a, b, c ... için SELECT * olup olmadığına bakılmaksızın her zaman tablonun meta verilerine başvuracaktır. Neden? Çünkü sistemdeki tablonun yapısı ve düzeni hakkındaki bilgiler burada.

Bu bilgileri iki nedenle okuması gerekir. Bir, basitçe ifadeyi derlemek için. En azından mevcut bir tabloyu belirttiğinizden emin olması gerekir. Ayrıca, bir ifadenin son çalıştırılmasından bu yana veritabanı yapısı değişmiş olabilir.

Şimdi, tabii ki, DB meta verileri sistemde önbelleğe alındı, ancak yapılması gereken hala işleniyor.

Ardından, meta veriler sorgu planını oluşturmak için kullanılır. Bu, bir ifade her derlendiğinde de olur. Yine, bu önbelleğe alınmış meta verilere karşı çalışır, ancak her zaman yapılır.

Bu işlemin yapılmadığı tek zaman, DB'nin önceden derlenmiş bir sorgu kullandığı veya önceki bir sorguyu önbelleğe aldığı zamandır. Bu, değişmez SQL yerine bağlama parametrelerini kullanma argümanıdır. "SEÇ * TABLEDEN NEREDE anahtar = 1" sorgudan farklı bir sorgu "SEÇ * TABLEDEN NEREDE anahtar =?" ve "1" çağrıya bağlıdır.

DB'ler orada çalışmak için sayfa önbelleğe alma işlemine büyük ölçüde güvenir. Çoğu modern DB, belleğe tamamen sığacak kadar küçüktür (veya, belki de modern belleğin birçok DB'ye uyacak kadar büyük olduğunu söylemeliyim). Ardından, arka uçtaki birincil G / Ç maliyetiniz günlüğe kaydetme ve sayfa temizlemedir.

Bununla birlikte, hala DB'niz için diske vuruyorsanız, birçok sistem tarafından yapılan birincil optimizasyon, tabloların kendileri yerine dizinlerdeki verilere güvenmektir.

Eğer varsa:

CREATE TABLE customer (
    id INTEGER NOT NULL PRIMARY KEY,
    name VARCHAR(150) NOT NULL,
    city VARCHAR(30),
    state VARCHAR(30),
    zip VARCHAR(10));

CREATE INDEX k1_customer ON customer(id, name);

Sonra "SELECT id, name FROM customer WHERE id = 1" yaparsanız, DB'niz bu verileri tablolardan değil dizinden çekmeniz çok olasıdır.

Neden? Sorguyu tatmin etmek için muhtemelen dizini kullanacaktır (tablo taramasına karşı) ve where cümlesinde 'ad' kullanılmasa da, bu dizin yine de sorgu için en iyi seçenek olacaktır.

Artık veritabanı sorguyu karşılamak için ihtiyaç duyduğu tüm verilere sahiptir, bu nedenle tablo sayfalarını kendilerinin vurması için bir neden yoktur. Dizinin kullanılması, genel olarak tabloya kıyasla dizinde daha yüksek bir satır yoğunluğuna sahip olduğunuzdan daha az disk trafiği ile sonuçlanır.

Bu, bazı veritabanları tarafından kullanılan belirli bir optimizasyon tekniğinin el dalgalı bir açıklamasıdır. Birçoğunun birkaç optimizasyon ve ayarlama tekniği vardır.

Sonunda, SELECT * elle yazmanız gereken dinamik sorgular için kullanışlıdır, "gerçek kod" için asla kullanmam. Tek tek sütunların tanımlanması, DB'ye sorguyu optimize etmek için kullanabileceği daha fazla bilgi verir ve şema değişikliklerine vb. Karşı kodunuzda size daha iyi kontrol sağlar.

Bence sorunuzun kesin bir cevabı yok, çünkü düşünen bir performansa ve uygulamalarınızın bakımını yapma olanağına sahipsiniz. Select columndaha performanslı select *, ancak odaklı bir nesne sistemi geliştiriyorsanız, o zaman kullanımı seveceksiniz object.propertiesve uygulamaların herhangi bir bölümünde bir özelliğe ihtiyacınız olabilir, o zaman özel durumlarda özellik elde etmek için daha fazla yöntem yazmanız gerekecektir. select *tüm özellikleri kullanın ve doldurun. Uygulamalarınızın kullanımının iyi bir performansa sahip olması gerekir select *ve bazı durumlarda performansı artırmak için seçme sütununu kullanmanız gerekir. O zaman, performansa ihtiyaç duyduğunuzda uygulamaları yazma ve sürdürme olanağına ve performansa sahip iki dünyanın en iyisine sahip olacaksınız.

Burada kabul edilen cevap yanlış. Bununla karşılaştım, başka bir soru bunun kopyası olarak kapatıldığında (hala cevabımı yazarken - grr - bu nedenle aşağıdaki SQL diğer soruya atıfta bulunuyor).

Her zaman SELECT özniteliğini, özniteliği kullanmalısınız ... SEÇMEYİN *

Öncelikle performans sorunları içindir.

Kullanıcılardan bir isim seçin WHERE name = 'John';

Çok faydalı bir örnek değil. Bunun yerine düşünün:

SELECT telephone FROM users WHERE name='John';

(İsim, telefon) üzerinde bir dizin varsa, tablodan ilgili değerlere bakmaya gerek kalmadan sorgu çözülebilir - bir kaplama indeksi vardır.

Ayrıca, tablonun kullanıcının bir resmini ve yüklenmiş bir CV'yi içeren bir BLOB'a sahip olduğunu ve SELECT * kullanan bir elektronik tablonun tüm bu bilgileri DBMS arabelleklerine geri çekeceğini varsayın (diğer yararlı bilgileri önbellekten dışarı atmaya zorlar). Daha sonra bunların tümü, gereksiz veriler için ağdaki çalışma süresi ve istemcideki bellek kullanılarak istemciye gönderilecektir.

İstemci verileri numaralandırılmış bir dizi olarak alırsa (PHP'nin mysql_fetch_array ($ x, MYSQL_NUM) gibi) işlevsel sorunlara da neden olabilir. Belki kod yazıldığında 'telefon' SELECT * tarafından döndürülecek üçüncü sütundu, ancak daha sonra birisi gelir ve masaya 'telefon'dan önce konumlandırılan bir e-posta adresi eklemeye karar verir. İstenilen alan şimdi 4. sütuna kaydırılmıştır.

Her iki şekilde de yapmak için sebepler var. PostgreSQL'de SELECT * 'i çok kullanıyorum çünkü PostgreSQL'de SELECT * ile yapabileceğiniz, özellikle de saklı yordamlarda açık bir sütun listesiyle yapamayacağınız pek çok şey vardır. Benzer şekilde, Informix'te, miras alınan bir tablo ağacı üzerindeki SELECT * size pürüzlü satırlar verebilirken, açık bir sütun listesi, alt tablolardaki ek sütunlar da döndürüldüğünden bunu yapamaz.

Bunu PostgreSQL'de yapmamın ana nedeni, bir tabloya özgü iyi biçimlendirilmiş bir tür elde etmemi sağlamasıdır. Bu, sonuçları alıp PostgreSQL'de tablo türü olarak kullanmamı sağlıyor. Bu ayrıca, sorguda katı bir sütun listesinden çok daha fazla seçeneğe izin verir.

Öte yandan, katı bir sütun listesi size db şemalarının belirli şekillerde değişmediğine dair uygulama düzeyinde bir kontrol sağlar ve bu yardımcı olabilir. (Bu tür kontrolleri başka bir düzeyde yaparım.)

Performans gelince, VIEW'leri ve türleri döndüren saklı yordamları (ve ardından saklı yordamın içindeki bir sütun listesini) kullanma eğilimindeyim. Bu, hangi türlerin döndürüleceğini kontrol etmemi sağlıyor.

Ancak SELECT * 'i genellikle temel tablolardan ziyade bir soyutlama katmanına karşı kullandığımı unutmayın.

Bu makaleden alınan referans:

SELECT * olmadan: O anda ”SELECT *” i kullandığınızda, veritabanından daha fazla sütun seçersiniz ve bu sütunun bir kısmı uygulamanız tarafından kullanılmayabilir. Bu, veritabanı sisteminde ekstra maliyet ve yük oluşturacak ve ağda daha fazla veri dolaşımı sağlayacaktır.

SELECT * ile: Özel gereksinimleriniz varsa ve sütun ekleme veya silme işlemi sırasında dinamik ortam oluşturduysanız, uygulama koduna göre otomatik olarak işlenir. Bu özel durumda, uygulama ve veritabanı kodunu değiştirmeniz gerekmez ve bu, üretim ortamını otomatik olarak etkileyecektir. Bu durumda “SEÇ *” i kullanabilirsiniz.

Burada görmediğim tartışmaya bir nüans eklemek için: G / Ç açısından, sütun odaklı depolamaya sahip bir veritabanı kullanıyorsanız yalnızca belirli bir sorgu yaparsanız çok daha az G / Ç yapabilirsiniz. sütunlar. SSD'lere geçtikçe, faydalar satır odaklı depolamaya göre biraz daha küçük olabilir, ancak a) yalnızca ilgilendiğiniz sütunları içeren blokları okumak b) genellikle diskteki verilerin boyutunu büyük ölçüde azaltan sıkıştırma ve dolayısıyla diskten okunan veri hacmi.

Sütun tabanlı depolamaya aşina değilseniz, Postgres için bir uygulama Citus Data'dan gelir, diğeri Greenplum, başka bir Paraccel, diğeri (gevşek bir şekilde konuşursak) Amazon Redshift'tir. MySQL için Infobright, hemen hemen feshedilen InfiniDB var. Diğer ticari teklifler arasında HP'den Vertica, Sybase IQ, Teradata ...

select * from table1 INTERSECT  select * from table2

eşit

select distinct t1 from table1 where Exists (select t2 from table2 where table1.t1 = t2 )