Örnek sorular
Mysql IndexesZorluk 1
InnoDB indeksleri B+-tree yapılar olarak organize edilir. Bir InnoDB B+-tree indeksinin leaf node'larında gerçekte ne saklanır?
- aSatırın tamamı (clustered index için) ya da clustered key'e bir referans (secondary index için) — asıl içeriği taşıyan leaf node'lardır✓
- bYalnızca insert sırasına göre sıralanmış, sabit disk-blok adreslerine pointer'lar
- cHer key değerini doğrudan bir satır offset'ine eşleyen bir hash tablosu
- dHer sayfanın sıkıştırılmış özetleri; gerçek veri yalnızca root node'da tutulur
Açıklama:InnoDB'nin B+-tree'sinde navigasyon key'leri iç node'larda, asıl payload ise leaf'lerdedir: clustered index (primary key) için leaf, satırın tüm kolonlarını tutar; secondary index için ise leaf, indekslenen kolonu artı satırı bulmak için kullanılan primary key değerini tutar. İç/root node'lar yalnızca aramayı yönlendirir, satır verisi tutmaz — bu yüzden (b), (c) ve (d) yanlıştır.
Mysql IndexesZorluk 1
InnoDB'de bir tablonun primary key'inin 'clustered index' olması ne anlama gelir?
- aPrimary key değerleri, satırların fiziksel saklanışıyla ilgisi olmadan, hızlı arama için ayrıca bellekte cache'lenir
- bTablonun gerçek satır verisi doğrudan primary key'in B+-tree leaf sayfalarının içinde, primary key'e göre fiziksel olarak sıralı yaşar✓
- cPrimary key kolonunun aynı anda birden fazla index tarafından kapsanması gerekir
- dSatırlar, primary key'in hash'ine göre sabit boyutlu partition'lara gruplanır
Açıklama:'Clustered index', tablo verisinin kendisinin index yapısı OLDUĞU anlamına gelir: satırlar, B+-tree leaf sayfalarının içinde primary key sırasına göre saklanır; işaret edilecek ayrı bir satır deposu yoktur. Bu, yalnızca bu clustered veriye işaret eden secondary index'lere sahip bir tablodan temel yapısal farktır. (a), (c) ve (d) InnoDB'nin bunun için kullanmadığı mekanizmaları tarif eder.
Mysql IndexesZorluk 2
users.email üzerinde bir secondary index var ve tablonun primary key'i id. Bu secondary index'in bir leaf-node girdisi gerçekte neyi içerir?
- aSatırın fiziksel olarak saklandığı sayfaya/offset'e doğrudan bir pointer; satır her taşındığında güncellenir
- bEşleşen satırın her kolonunun tam bir kopyası; clustered index ile senkron tutulur
- cİndekslenen
email değeri artı primary key değeri; bu değer daha sonra clustered index'te tam satırı bulmak için kullanılır✓ - dYalnızca
email değeri; secondary index tek başına satırın geri kalanını almak için hiçbir zaman kullanılamaz
Açıklama:InnoDB secondary index leaf'leri, indekslenen kolon(lar)ı artı satırın primary key değer(ler)ini saklar, fiziksel bir pointer değil. Diğer kolonları almak için InnoDB, bu primary key ile clustered index'e ikinci bir arama yapar — bu dolaylılık, InnoDB'de PK seçiminin secondary-index performansı için bu kadar önemli olmasının tam sebebidir. (a) InnoDB'nin kullanmadığı fiziksel-pointer modelini tarif eder, (b) ve (d) neyin saklandığını ve alınabilir olduğunu yanlış anlatır.
Mysql IndexesZorluk 1
Bir tablo hiçbir PRIMARY KEY ve hiçbir UNIQUE NOT NULL index olmadan yaratılıyor. InnoDB bu durumda clustered index olarak dahili olarak neyi kullanır?
- aAçık bir primary key eklenene kadar tabloyu hiç yaratmayı reddeder
- bSessizce yalnızca o tablo için MyISAM tarzı heap depolamaya döner
- cTipi ne olursa olsun
CREATE TABLE'da ilk tanımlanan kolonu kullanır - dGizli, dahili bir
ROW_ID kolonu üretir ve tabloyu bu kolon üzerinde kümeler✓
Açıklama:InnoDB her tablonun bir clustered index'e sahip olmasını gerektirir. PRIMARY KEY deklare edersen o kullanılır; yoksa ilk UNIQUE NOT NULL index seçilir; ikisi de yoksa InnoDB sessizce görünmez, otomatik-artan bir ROW_ID kolonu ekler ve tabloyu onun üzerinde kümeler. Tablo yine de yaratılır (a'yı eler), InnoDB kalmaya devam eder (b'yi eler), kolon sırası/tipi rol oynamaz (c'yi eler).
Mysql IndexesZorluk 2
EXPLAIN SELECT * FROM orders WHERE customer_id = 42;
possible_keys: idx_customer_id,PRIMARY ve
key: idx_customer_id döner. Burada
key kolonu ile
possible_keys kolonu arasındaki fark nedir?
- a
key, optimizer'ın bu sorguyu çalıştırmak için gerçekten seçtiği tek index'tir; possible_keys yalnızca değerlendirdiği aday index'leri listeler✓ - b
key, tabloda var olan her index'i listeler; possible_keys gelecekteki bir sorguda kullanılması planlanan index'leri listeler - c
key ve possible_keys her zaman aynıdır; MySQL sadece eski client uyumluluğu için bilgiyi tekrarlar - d
key yalnızca primary key index'ini gösterir; possible_keys ilgisi ne olursa olsun yalnızca secondary index'leri gösterir
Açıklama:possible_keys, optimizer'ın sorgunun predicate'lerini karşılayabilecek index'lerden oluşan kısa listesidir; key ise maliyet tahmininden sonra gerçekten kullanmaya karar verdiği tek index'tir. Burada hem idx_customer_id hem PRIMARY uygulanabilirdi ama yalnızca idx_customer_id seçildi. (b), (c), (d) iki kolon arasındaki ilişkiyi yanlış tarif eder.
Mysql IndexesZorluk 2
Bir sorgu, customer_id'nin INT (4 byte) olduğu composite bir index (customer_id, order_date) kullanıyor. EXPLAIN, key_len: 4 gösteriyor. Bu değer sana ne söyler?
- aIndex bu sorgu için tam olarak 4 eşleşen girdi içeriyor
- bComposite key'den yalnızca baştaki
customer_id kolonu (4 byte) kullanılıyor — order_date burada index aramasının parçası değil✓ - cToplamda 4 kolona yayılan tüm composite index kullanılıyor
- dIndex scan geri dönmeden önce tam olarak 4 index sayfasına dokundu
Açıklama:key_len, sorguyu karşılamak için index key'inin kaç byte'ının gerçekten kullanıldığını bildirir; bu, composite bir index'in kaç baştaki kolonunun aramaya katıldığının doğrudan sinyalidir. key_len: 4 değeri tam olarak customer_id'nin boyutuna eşit olduğundan, sorgu yalnızca o baştaki kolonu kullandı — order_date, index üzerinden uygulanan aralık/eşitlik koşulunun parçası değildi. Satır sayısıyla (a), sayfa sayısıyla (d) ya da toplam kolon sayısıyla (c) ilgisi yoktur.