Yanıtlar:
Tam tablo taramalarının kötü ve indeks erişiminin iyi olduğuna dair yorumlar gördüğümde titriyorum. Tam tablo taramaları, dizin aralığı taramaları, hızlı tam dizin taramaları, iç içe döngüler, birleştirme birleştirme, karma birleştirme vb., Analist tarafından anlaşılması gereken ve veritabanı yapısı bilgisi ve bir sorgunun amacı ile birleştirilmesi gereken basit erişim mekanizmalarıdır. anlamlı bir sonuca ulaşmak için.
Tam bir tarama, bir veri segmentinin (bir tablo veya bir tablo (alt) bölümü) bloklarının büyük bir bölümünü okumanın en verimli yoludur ve genellikle bir performans sorununu gösterebilirken, bu yalnızca bağlamda geçerlidir. sorgunun hedeflerine ulaşmak için etkili bir mekanizma olup olmadığı. Bir veri ambarı ve BI görevlisi olarak konuşursak, performans için bir numaralı uyarı bayrağım, indeks tabanlı bir erişim yöntemi ve iç içe bir döngüdür.
Bu nedenle, bir açıklama planının nasıl okunacağına ilişkin mekanizma için Oracle belgeleri iyi bir kılavuzdur: http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/ex_plan.htm#PFGRF009
Performans Ayarlama Kılavuzunu da okuyun.
Ayrıca, bir sorguda çeşitli aşamalardaki kardinalite tahminlerini yürütme sırasında deneyimlenen gerçek kardinalitelerle karşılaştırmak için bir açıklama planının kullanılabileceği bir teknik olan "kardinalite geri bildirimi" için bir Google'a sahip olun. Wolfgang Breitling'in yöntemin yazarı olduğuna inanıyorum.
Sonuç olarak: erişim mekanizmalarını anlayın. Veritabanını anlayın. Sorgunun amacını anlayın. Genel kurallardan kaçının.
Bu konu böyle bir soruda cevaplanamayacak kadar büyük. Oracle'ın Performans Ayarlama Kılavuzunu okumak için biraz zaman ayırmalısınız
Aşağıdaki iki örnek, bir TAM taramayı ve bir INDEX kullanan bir FAST taramayı göstermektedir.
Maliyet ve Önem düzeyinize konsantre olmak en iyisidir. Örneklere bakıldığında, dizinin kullanımı sorguyu çalıştırma maliyetini düşürür.
Bu biraz daha karmaşıktır (ve bunu% 100 ele alamıyorum) ancak temelde Maliyet, CPU ve GÇ maliyetinin bir fonksiyonudur ve Önem, Oracle'ın ayrıştırmayı beklediği satır sayısıdır. Bunların ikisini de azaltmak iyi bir şeydir.
Bir sorgunun Maliyetinin, sorgunuzdan ve Oracle optimizasyon modelinden (örneğin: COST, CHOOSE vb.) Ve istatistiklerinizi ne sıklıkla çalıştırdığınızdan etkilenebileceğini unutmayın.
Örnek 1:
TARAMA http://docs.google.com/a/shanghainetwork.org/File?id=dd8xj6nh_7fj3cr8dx_b
Dizinlerin kullanıldığı Örnek 2:
DİZİN http://docs.google.com/a/fukuoka-now.com/File?id=dd8xj6nh_9fhsqvxcp_b
Ve daha önce önerildiği gibi, TABLO TARAMA'ya dikkat edin. Genelde bunlardan kaçınabilirsiniz.
Sıralı taramalar gibi şeyler aramak biraz yararlı olabilir, ancak gerçek sayılarda gizlidir ... sayıların yalnızca tahmin olduğu durumlar dışında! Genellikle bir sorgu planına bakmaktan çok daha yararlı olan , gerçek uygulamaya bakmaktır . Postgres'de bu EXPLAIN ve EXPLAIN ANALYZE arasındaki farktır. EXPLAIN ANALYZE, aslında sorguyu yürütür ve her düğüm için gerçek zamanlama bilgisi alır. Bu , planlayıcının olacağını düşündüğü şey yerine gerçekte neler olduğunu görmenizi sağlar . Çoğu zaman, sıralı bir taramanın hiç sorun olmadığını, bunun yerine sorguda başka bir şey olduğunu göreceksiniz.
Diğer anahtar ise asıl pahalı adımın ne olduğunu belirlemektir. Birçok grafik araç, planın farklı bölümlerinin maliyetini belirtmek için farklı boyutlu oklar kullanır. Bu durumda, ince okların geldiği ve kalın bir okun çıktığı adımları arayın. Bir GUI kullanmıyorsanız, sayılara dikkat etmeniz ve aniden çok daha büyük oldukları yerleri aramanız gerekir. Biraz alıştırma ile sorunlu alanları belirlemek oldukça kolay hale gelir.
Gerçekten bunun gibi sorunlar için yapılacak en iyi şey ASKTOM'dur . Özellikle bu soruya verdiği yanıt, bu türden kuralların çoğunun açıklandığı çevrimiçi Oracle belgesine bağlantılar içerir.
Akılda tutulması gereken bir şey, planları açıklamanın gerçekten en iyi tahminler olduğudur.
Sqlplus'ı kullanmayı öğrenmek ve AUTOTRACE komutunu denemek iyi bir fikir olacaktır. Bazı kesin rakamlarla, genellikle daha iyi kararlar verebilirsiniz.
Ama SORMALISINIZ. Her şeyi biliyor :)
Açıklamanın çıktısı size her adımın ne kadar sürdüğünü söyler. İlk şey, uzun zaman alan adımları bulmak ve ne anlama geldiklerini anlamak. Sıralı tarama gibi şeyler size daha iyi dizinlere ihtiyacınız olduğunu söyler - bu çoğunlukla belirli veri tabanınız ve deneyimlerinizle ilgili bir araştırma meselesidir.
Bir "Oh hayır, bu doğru değil" çoğu zaman bir tablo taraması biçimindedir . Tablo taramaları herhangi bir özel dizin kullanmaz ve bellek önbelleğindeki her yararlı şeyin temizlenmesine katkıda bulunabilir. Örneğin postgreSQL'de bunun böyle göründüğünü göreceksiniz.
Seq Scan on my_table (cost=0.00..15558.92 rows=620092 width=78)
Bazen tablo taramaları, örneğin satırları sorgulamak için bir dizin kullanmak için idealdir. Ancak bu, aradığınız görünen kırmızı bayrak modellerinden biridir.
Temel olarak, her operasyona bir göz atarsınız ve nasıl çalışması gerektiğine dair bilginize göre operasyonların "mantıklı" olup olmadığını görürsünüz.
Örneğin, iki tabloyu, A ve B'yi ilgili sütunlarında C ve D (AC = BD) birleştiriyorsanız ve planınız tabloda kümelenmiş bir dizin taraması (SQL Server terimi - oracle teriminden emin değil) gösteriyorsa A, sonra bir dizi kümelenmiş dizine iç içe bir döngü birleşimi tablo B'yi arar, bir sorun olduğunu düşünebilirsiniz. Bu senaryoda, motorun bir çift dizin taraması (birleştirilmiş sütunlardaki dizinler üzerinde) ve ardından bir birleştirme birleştirmesi yapmasını bekleyebilirsiniz. Daha fazla araştırma, optimize edicinin bu birleştirme modelini veya gerçekte var olmayan bir dizini seçmesine neden olan kötü istatistikleri ortaya çıkarabilir.
Planın her bir alt bölümünde harcanan zamanın yüzdesine bakın ve motorun ne yaptığını düşünün. örneğin, bir tablo tarıyorsa, taranan alan (lar) a bir dizin koymayı düşünün.
Esas olarak dizin veya tablo taramalarını arıyorum. Bu genellikle bana where ifadesindeki veya join ifadesindeki önemli bir sütundaki bir dizini kaçırdığımı söylüyor.
Gönderen http://www.sql-server-performance.com/tips/query_execution_plan_analysis_p1.aspx :
Bir yürütme planında aşağıdakilerden herhangi birini görürseniz, bunları uyarı işaretleri olarak değerlendirmeli ve potansiyel performans sorunları açısından incelemelisiniz. Performans açısından her biri idealden daha az.
* Index or table scans: May indicate a need for better or additional indexes. * Bookmark Lookups: Consider changing the current clustered index, consider using a covering index, limit the number of columns in the SELECT statement. * Filter: Remove any functions in the WHERE clause, don't include wiews in your Transact-SQL code, may need additional indexes. * Sort: Does the data really need to be sorted? Can an index be used to avoid sorting? Can sorting be done at the client more efficiently?Bunlardan kaçınmak her zaman mümkün değildir, ancak bunlardan ne kadar kaçınırsanız sorgu performansı o kadar hızlı olacaktır.
(muhtemelen ayrıntıları da okumak istersiniz:
Birkaç Büyük Tablonun Tablo Taramaları
Benzersiz bir dizin kullanma
Dizin gerekli tüm alanları içerir
Gördüğüm performans sorunlarının yaklaşık% 90'ında en kolay kazanç, çok sayıda (4 veya daha fazla) tablodan oluşan bir sorguyu 2 küçük sorgu ve geçici bir tabloya bölmektir.