MyISAM ve InnoDB'nin En İyileri

InnoDB'nin, eşzamanlılık performansından yararlanırken RAM sınırlaması nedeniyle kümelenmiş dizin yerine MyISAM ile aynı dizinleri kullanmasını sağlamak mümkün müdür?

Gen_clust_index InnoDB kaputunun altında (kümelenmiş indeks) ROWIDs birlikte birincil anahtarların girdileri evler. Gen_clust_index'in kullanımıyla ilgili ilginç olan, yarattığınız benzersiz olmayan dizinlerin her zaman bir tablonun gen_clust_index için karşılık gelen bir satır kimliğine sahip olmasıdır. Bu nedenle, biri ikincil dizin ve biri gen_clust_index için olmak üzere her zaman çift dizin araması vardır.

Bir tablonun veya birincil anahtarın düzenini iyileştirme girişimleri, gen_clust_index veya en azından marjinal sonuçlar nedeniyle geçersiz kılınır.

MİSAL

Bazı insanlar MyISAM'ı PRIMARY KEY düzeninde sıralamaya çalışır. Göre MySQL Veritabanı Tasarımı ve Tuning, Sayfa 236 "endeksi Order bir Tablo saklanması" alt başlığı altında Paragraf 7:

Bir tablodan sık sık dizinlenmiş veri aralıklarını alırsanız veya sonuçları aynı dizin anahtarında tutarlı bir şekilde sıralarsanız, myisamchk dosyasını --sort-kayıt seçeneği ile çalıştırmayı düşünebilirsiniz. Bunu yaparak MySQL'e tablonun verilerini dizinle aynı fiziksel sırada sıralamasını söyleyin ve bu tür işlemlerin hızlanmasına yardımcı olabilir. Alternatif olarak, aynı sonuçları elde etmek için ALTER TABLE deyimini ORDER BY ile belirli bir sütun seçeneğiyle birleştirebilirsiniz.

Bu MyISAM için etkili bir şekilde çalışıyor ve çalışıyor . Sütunları PRIMARY KEY olabilir veya olmayabilir InnoDB karşı ALTER TABLE ... ORDER BY col1, col2, ..., coln gerçekleştirebilirsiniz. Bu InnoDB için daha hızlı sonuçlar üretmeyecektir, çünkü ... bu doğru ... her seferinde gen_clust_index'e danışmalısınız.

Bazı kişiler tablonun satır biçimini SABİT kullanarak ALTER TABLE mydb.mytb ROW_FORMAT=Fixed;yapabilir ve başka bir değişiklik yapmadan okuma performansında% 20 artış elde edebilir. Bu, MyISAM için etkili bir şekilde çalışır ve çalışır . Bu InnoDB için daha hızlı sonuçlar üretmeyecektir, çünkü ... bu doğru ... her seferinde gen_clust_index'e danışmalısınız.

Mydb.mytb adlı bir InnoDB tablosunda aşağıdakileri yapabilirsiniz:

CREATE TABLE mydb.mytc LIKE mydb.mytb;
INSERT INTO mydb.mytc SELECT * FROM mydb.mytb ORDER BY col1,col2,...coln;
ALTER TABLE mydb.mytb RENAME mydb.mytd;
ALTER TABLE mydb.mytc RENAME mydb.mytb;
DROP TABLE mydb.mytd;

Bu, tabloyu gen_clust_index içinde rowid düzenine yerleştirir. Bu InnoDB için marjinal sonuçlar doğurabilir çünkü ... bu doğru ... her seferinde gen_clust_index'e danışmalısınız.

Şimdi biraz saçmalayalım. Sorgulanacak bir NoSQL arabirimi vardır (yalnızca SELECT) MyISAM ve InnoDB, HandlerSocket (eski adıyla HANLDER) arabirimi olarak adlandırılır . Bu, tüm SQL, ACID ve MVCC protokollerini atlamanızı sağlayan verilere erişmenizi sağlar . Mümkün olsa da, IMHO KOD VE BAKIM İÇİN ÇOK KOMPLE ETTİ. AFAIK, HandlerSocket arabiriminin gen_clust_index ile etkileşime girip girmediğini gösteren hiçbir şey yoktur.

Özetle, bir kedinin derisini almanın birçok yolu vardır. Bu durumda, kediyi tutamazsınız (gen_clust_index). MyISAM'ın okuma performansı, tablo sıralamasındaki esnekliği, tablo satırı formatı ve onu destekleyen araçlar nedeniyle var olmaya devam etmesinin nedeni budur. InnoDB, bazı cesur ruhlar InnoDB kaynak kodunu alıp hem MyISAM hem de InnoDB'den en iyisine sahip bir şeye dönüştürene kadar ACID uyumlu doğası etrafında tasarlanmaya devam edecektir .

Kümelenmiş dizin belki de geleneksel sıkma sürücülerde InnoDB'nin en eşzamanlılık performansı için sebep.

Kümelenmiş dizin aracılığıyla bir satıra erişmek hızlıdır çünkü satır verileri dizin aramasının yönlendirdiği aynı sayfadadır. Bir tablo büyükse, kümelenmiş dizin mimarisi, satır verilerini dizin kaydından farklı bir sayfa kullanarak depolayan depolama kuruluşlarıyla karşılaştırıldığında genellikle bir disk G / Ç işlemi kaydeder. (Örneğin, MyISAM veri satırları için bir dosya ve dizin kayıtları için başka bir dosya kullanır.)

Disk G / Ç pahalıdır. Yani bunu azaltmak eşzamanlılığı artırmak için büyük bir faydadır.

Disk G / Ç daha ucuz ve bir darboğazdan daha az olmaya başlarsa (ör. SSD teknolojisi daha kararlı hale geldikçe), Oracle InnoDB dizinlerinin çalışma şeklini değiştirmeye karar verebilir. Muhtemelen aynı kalacaktır, çünkü aynı teknoloji 'RAM sınırlamasını' daha az sorun haline getirecektir.

Kısa cevap: Hayır.

InnoDB kümeleri birincil anahtar aracılığıyla ve birincil anahtarın yokluğunda ilk benzersiz dizini seçer. Benzersiz bir dizin olmadığında, kümeleme için gizli bir 6 bayt anahtar oluşturur.

Gizli 6 bayt anahtarına sahip olduğunuzda, ikincil dizinler satır konumlarına (MyISAM'daki gibi) tam işaretçiler yerine bu anahtara başvurur, böylece ikincil bir anahtar geçişi ve ardından kayıtlarınızı bulmak için birincil anahtar geçişi elde edersiniz .

Sorunuzdan biraz tahmin etmek için, bir ağaçla bellek uyumu konusunda endişelendiğinizi varsayıyorum, çünkü verimli bir şekilde arama yapmak için, tüm kök düğümler bellekte olmalıdır, çünkü yaprak sayfalarınızı bulmak için her zaman bu yolda yürümeniz gerekir mi?

Bu doğrudur, ancak bir teselli, ticari veritabanlarının ağaçlarını derinden ziyade mümkün olduğunca yağ yapmaya çalışmasıdır. Görmek için verilerinizde xtrabackup --stats komutunu çalıştırmayı deneyin . Örneğin:

<INDEX STATISTICS>
  table: test/table1, index: PRIMARY, space id: 12, root page 3
  estimated statistics in dictionary:
    key vals: 25265338, leaf pages 497839, size pages 498304
  real statistics:
     level 2 pages: pages=1, data=5395 bytes, data/pages=32%
     level 1 pages: pages=415, data=6471907 bytes, data/pages=95%
        leaf pages: recs=25958413, pages=497839, data=7492026403 bytes, data/pages=91%

497839 yaprak sayfası vardı (~ 8GB), ancak yalnızca 416 sayfa yukarıda (6.5MB) vardı. Bu komutu üretim verileri üzerinde birkaç kez çalıştırdım ve milyonlarca milyar kayıt ve sadece seviye 1-3 sayfa + yaprak sayfalar olduğunda her zaman beni şaşırtıyor.