g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

Beş SQL sorgu performans testi sorusu yalnızca% 40 geçme oranına sahiptir. Meydan okumaya cesaretiniz var mı? | Güç Projesi

Yazar | Dong Xuyang TonyDong, CSDN blog uzmanı

Editör | Tang Xiaoyin

Baş resmi | Oriental IC'den indirilen CSDN

Üretildi | CSDN Blogu

Aşağıda indeksleme ve SQL sorgu performansı ile ilgili 5 test sorusu bulunmaktadır; bunlardan 4 tanesi ikisinden birinin cevabı ve bir soru üçünden biridir. 3 doğru cevap aldığınız sürece, başarılı sayılacaksınız Basit görünüyor mu? Ama aslında insanların sadece% 40'ı geçebiliyor. Test sorularının sonunda cevapların bir analizini vereceğiz, ancak önce denemenizi ve doğru cevapları alıp almadığınızı görmenizi öneririm!

Soru 1

Aşağıdaki sorgu ifadelerinin performans sorunları var mı?

TABLO OLUŞTUR t1 ( id INT NOT, dt DATE, BİRİNCİL ANAHTAR (kimlik) ); T1 (dt) ÜZERİNDE INDEX idx1 OLUŞTUR; SEÇ * T1'DEN NEREDE TO_CHAR (dt, 'YYYY') = '2019'; - Oracle, PostgreSQL - YIL (dt) = '2019'; - MySQL - WHERE datepart (yyyy, dt) = '2019'; - SQL Server

Seçenek A: Sorun değil;

Seçenek B: Bir sorun var.

soru 2

Aşağıdaki sorgu ifadelerinin performans sorunları var mı?

TABLO OLUŞTUR t2 ( id INT NOT, ben INT dt DATE, v VARCHAR (50), BİRİNCİL ANAHTAR (kimlik) ); T2 (i, dt) ÜZERİNDE INDEX idx2 OLUŞTUR; SEÇ * T2'den itibaren NEREDE i = 99 Dt DESC İLE SİPARİŞ YALNIZCA İLK 5 SIRA FETCH; - Oracle, SQL Server, PostgreSQL - OFSET 0 SIRA YALNIZCA İLK 5 SIRA FETCH; - SQL Server - SINIR 5; - MySQL

Seçenek A: Sorun değil;

Seçenek B: Bir sorun var.

Soru 3

Aşağıdaki tablodaki dizinler ile ilgili herhangi bir sorun var mı?

TABLO OLUŞTUR t3 ( id INT NOT, col1 INT, col2 INT, col3 VARCHAR (50), BİRİNCİL ANAHTAR (kimlik) ); T3 ÜZERİNDE INDEX idx3 OLUŞTUR (sütun1, sütun2); SEÇ * T3'DEN NEREDE col1 = 99 VE col2 = 10; SEÇ * T3'DEN NEREDE col2 = 10;

Seçenek A: Sorun değil;

Seçenek B: Bir sorun var.

Soru 4

Aşağıdaki sorgu ifadelerinin performans sorunları var mı?

TABLO OLUŞTUR t4 ( id INT NOT, col1 INT, col2 VARCHAR (50), BİRİNCİL ANAHTAR (kimlik) ); T4 (sütun2) AÇIK INDEX idx4 OLUŞTUR; SEÇ * T4'DEN Col2 GİBİ '% sql%';

Seçenek A: Sorun değil;

Seçenek B: Bir sorun var.

Soru 5

Aşağıdaki tablo ve iki sorgu ifadesi varsa, hangi sorgu daha hızlıdır?

TABLO OLUŞTUR t5 ( id INT NOT, col1 INT, col2 INT, col3 VARCHAR (50), BİRİNCİL ANAHTAR (kimlik) ); T5 ÜZERİNDE INDEX idx5 OLUŞTUR (sütun1, sütun3); Col3 SEÇİN, say (*) T5'ten NEREDE col1 = 99 GROUP BY col3; Col3 SEÇİN, say (*) T5'ten NEREDE col1 = 99 VE col2 = 10 GROUP BY col3;

Seçenek A: İlk sorgu daha hızlıdır;

Seçenek B: İkinci sorgu daha hızlıdır;

Seçenek C: İki sorgunun performansı benzerdir.

Ayrıştırma

Soru 1

Cevap şu: B, bir performans sorunu var. Çünkü Dizin alanlarında işlev veya ifadelerin kullanılması dizinin geçersiz olmasına neden olur.

İfadenin yürütme planını görüntülemek için EXPLAIN komutunu kullanabilirsiniz. İlk olarak tablonun istatistiksel analizini yapmak en iyisidir:

- Oracle PLANI AÇIKLAYIN SEÇ * T1'DEN NEREDE TO_CHAR (dt, 'YYYY') = '2019'; TABLEDEN SEÇ * (dbms_xplan.display); PLAN_TABLE_OUTPUT | -------------------------------------------------- ------------------------ | Plan karma değeri: 3617692013 | | -------------------------------------------------- ------------------------ | | Kimlik | İşlem | Ad | Satırlar | Bayt | Maliyet (% CPU) | Zaman || -------------------------------------------------- ------------------------ | | 0 | İFADE SEÇ | | 1 | 22 | 2 (0) | 00:00:01 || | * 1 | TABLO ERİŞİMİ TAM | T1 | 1 | 22 | 2 (0) | 00:00:01 || -------------------------------------------------- ------------------------ | | Tahmin Bilgileri (işlem kimliği ile tanımlanır): | -------------------------------------------------- - | | 1-filtre (TO_CHAR (INTERNAL_FUNCTION ("DT"), 'YYYY') = '2019') | | Not | ----- | kullanılan dinamik istatistikler: dinamik örnekleme (seviye = 2) |

Oracle'da tam bir tablo taramasıdır ve indeks alınmaz. MySQL'e tekrar bakın:

- MySQL SEÇİMİ AÇIKLAYIN * T1'DEN YIL (dt) = '2019'; id | seçme_türü | tablo | bölümler | tür | olası anahtarlar | anahtar | anahtar_len | başvuru | satırlar | filtrelenmiş | Ekstra | - | ----------- | ----- | ---------- | ----- | ------------ - | ---- | ------- | --- | ---- | -------- | ----------------- ------- | 1 | BASİT | t1 | | indeks | | idx1 | 4 | | 1 | 100 | Nerede kullanımı; İndeksi kullanma |

MySQL bir indeks kullansa da, aynı zamanda indeks üzerinde dönüştürme yargılamaları yapması gerekir; bu optimal çözüm değildir.

Sırada SQL Server var:

- SQL Server İSTATİSTİK PROFİLİ AYARLA SEÇ * T1'DEN NEREDE tarih bölümü (yyyy, dt) = '2019'; Satırlar | Yürütme | StmtText | StmtId | DüğümKimliği | Üst Öğe | FizikselOp | MantıksalOp | Bağımsız Değişken | Tanımlı Değerler | TahminSüreleri | TahminIO | Tahmin CPU | OrtRowSize | ToplamAltAğaçMüşteri | ÇıktıListesi | Uyarılar | Tür | Paralel | Tahminİfadeleri | ---- | -------- | ------------------------------------ -------------------------------------------------- ------------------- | ------ | ------ | ------ | --------- - | ---------- | ------------------------------------- -------------------------------------------------- - | ---------------------------------------------- | - ----------- | --------------------- | ---------------- ----- | ---------- | --------------------- | ----------- ----------------------------------- | -------- | ----- --- | -------- | ------------------ | 0 | 1 | SEÇİN * t1 NEREDEN datepart (yyyy, dt) = '2019' | 1 | 1 | 0 | | | | 1 | | | | 0.0032830999698489904 | | | SEÇ | 0 | | 0 | 1 | | --Index Tarama (NESNE: [...), NEREDE: (datepart (yıl, ...) = [2019))) | 1 | 2 | 1 | Dizin Tarama | Dizin Tarama | NESNE: [...), NEREDE: (datepart (year, ...) = (2019)) | ..., ... | 1 | 0.0031250000465661287 | 1.5809999604243785E-4 | 14 | 0.0032830999698489904 | ..., .. . | | PLAN_ROW | 0 | 1 |

SQL Server bir dizin kullanır, ancak aynı zamanda dizin üzerinde bir dönüştürme kararı vermesi gerekir; bu optimal çözüm değildir.

Son olarak, PostgreSQL'e bakın:

- PostgreSQL SEÇİMİ AÇIKLAYIN * T1'DEN NEREDE TO_CHAR (dt, 'YYYY') = '2019'; SORGU PLANI | -------------------------------------------------- ------------------------------ | Sıralı Tarama t1 (maliyet = 0.00..49.55 satır = 11 genişlik = 8) | Filtre: (to_char ((dt) :: saat dilimli zaman damgası, 'YYYY' :: text) = '2019' :: metin) |

PostgreSQL tam bir tablo taraması kullanır ve indeksler kullanmaz.

Doğru yol, sorgu ifadesini değiştirmektir:

SEÇ * T itibaren Dt TARİH '2019-01-01' İLE TARİH '2019-12-31' ARASINDA;

Uyarılar: İşlevsel bir dizin kullanmak en iyi çözüm değildir, yalnızca belirli sorgu koşulları için kullanılabilir; sorgu koşulları TO_CHAR (dt, 'YYYY-AA-GG') = '2019-06-01' veya diğer biçimlere değiştirilirse, Dizini kullanın.

soru 2

Cevap şu: A, performansla ilgili bir sorun yok. Cümle Hem WHERE yan tümcesi hem de ORDER BY yan tümcesi dizinleri kullanabilir (Ters tarama), herhangi bir satırın ek olarak sıralanmasına gerek yoktur. Yürütme planını görüntülemek için yukarıdaki yöntemi kullanabilirsiniz.

Soru 3

Cevap şu: B, endeksle ilgili bir sorun var. Çünkü ikinci sorgu indeksi kullanamaz veya verimli değildir. Bazı veritabanları dizin atlama taramasını kullanabilse de, dizin alanlarının sırasını değiştirerek daha iyi performans elde edilebilir:

T3 ÜZERİNDE INDEX idx3 OLUŞTURMA (sütun2, sütun1);

Dizinin sol ucuna col2 koyun ve her iki sorgu da dizini kullanabilir; yani, Bileşik indeks en soldaki önek ilkesini izlemelidir . Ek olarak, col2'ye dayalı bir dizin oluşturmak, dizin çoğaltmasına neden olur ve bu iyi bir çözüm değildir.

Soru 4

Cevap şu: B, bir performans sorunu var. Çünkü LIKE koşulunda,% veya _ joker karakteriyle başlayan dize, dizini kullanamaz . Ancak, aşağıdaki ifadeler dizinleri kullanabilir:

SEÇ * T4'DEN Col2 GİBİ NEREDE'sql% ';

PostgreSQL için, bir dizin oluştururken operatör sınıfını da belirtmeniz gerekir:

- PostgreSQL T4 ÜZERİNDE INDEX idx4 OLUŞTURMA (col2 varchar_pattern_ops);

Soru 5

Cevap: A, ilk sorgu daha hızlı. Bundan dolayı Sonucu almak için yalnızca dizini taramanız gerekir (Yalnızca Dizin Tarama) ; İkinci sorgu daha az veri döndürebilmesine rağmen tabloya indeks üzerinden yani tabloya dönmesi gerekiyor.

Sevgili dostum, kaç cevabı doğru aldın? Tartışmak için bir mesaj bırakmaya hoş geldiniz!

Makale yayınlama yetkisi yazar tarafından verildi, CSDN blog yayını adresi:

https://blog.csdn.net/horses/article/details/103028340

Dağıtılmış teknolojiyi öğrenin, teknik insanlar buraya bakın

Dharma Akademisi 2020 On Teknoloji Trendi Yayınlandı: Teknolojik Dalgaların Yeni On Yılı İçin Giriş