Best of MyISAM dan InnoDB

Apakah mungkin untuk membuat InnoDB menggunakan indeks yang sama dengan MyISAM alih-alih indeks berkerumun karena keterbatasan RAM sambil mendapatkan manfaat dari kinerja konkurensi?

The gen_clust_index (clustered index) di bawah kap InnoDB rumah entri kunci utama bersama dengan ROWIDs. Apa yang menarik tentang penggunaan gen_clust_index adalah kenyataan bahwa setiap indeks non-unik yang Anda buat akan selalu memiliki rowid yang sesuai untuk gen_clust_index dari sebuah tabel. Jadi, selalu ada pencarian indeks ganda, satu untuk indeks sekunder dan satu untuk gen_clust_index.

Setiap upaya untuk meningkatkan tata letak tabel atau kunci utama akan dibatalkan karena gen_clust_index, atau setidaknya hasil marginal yang terbaik.

CONTOH

Beberapa orang berusaha untuk mengurutkan MyISAM dalam urutan KUNCI UTAMA. Menurut Desain dan Tuning Basis Data MySQL, di bawah judul "Menyimpan Tabel dalam Urutan Indeks":

Jika Anda sering mengambil rentang besar dari data yang diindeks dari tabel atau secara konsisten mengurutkan hasil pada kunci indeks yang sama, Anda mungkin ingin mempertimbangkan menjalankan myisamchk dengan opsi --sort-records. Melakukannya memberitahu MySQL untuk mengurutkan data tabel dalam urutan fisik yang sama dengan indeks, dan dapat membantu mempercepat operasi semacam ini. Atau, Anda bisa menggabungkan pernyataan ALTER TABLE dengan ORDER BY opsi kolom tertentu untuk mencapai hasil yang sama.

Memang, ini bekerja dan bekerja secara efektif UNTUK MyISAM . Anda dapat melakukan ALTER TABLE ... ORDER BY col1, col2, ..., coln terhadap InnoDB di mana kolom mungkin atau mungkin bukan yang dari KUNCI UTAMA. Ini tidak akan menghasilkan hasil yang lebih cepat untuk InnoDB karena ... itu benar ... Anda harus berkonsultasi dengan gen_clust_index setiap kali.

Beberapa orang dapat membuat format baris tabel TETAP menggunakan ALTER TABLE mydb.mytb ROW_FORMAT=Fixed;dan bisa mendapatkan peningkatan 20% dalam kinerja membaca tanpa perubahan lainnya. Ini bekerja dan bekerja secara efektif UNTUK MyISAM . Ini tidak akan menghasilkan hasil yang lebih cepat untuk InnoDB karena ... itu benar ... Anda harus berkonsultasi dengan gen_clust_index setiap kali.

Anda bisa melakukan hal berikut pada tabel InnoDB bernama mydb.mytb:

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;

Ini akan menempatkan tabel dalam urutan rowid di gen_clust_index. Ini mungkin menghasilkan hasil marginal untuk InnoDB terbaik karena ... itu benar ... Anda harus berkonsultasi dengan gen_clust_index setiap kali.

Sekarang, mari kita menjadi sedikit konyol. Ada antarmuka NoSQL untuk kueri (hanya PILIH) MyISAM dan InnoDB disebut antarmuka HandlerSocket (sebelumnya disebut HANLDER) . Ini memberi Anda akses ke data yang memungkinkan Anda mem-bypass semua protokol SQL, ACID , dan MVCC . Meskipun mungkin, IMHO CARA TERLALU BANYAK UNTUK KODE DAN JAGA. AFAIK tidak ada dalam cetakan yang menyatakan apakah antarmuka HandlerSocket berinteraksi dengan gen_clust_index atau tidak.

Singkatnya, ada banyak cara untuk menguliti kucing. Dalam hal ini, Anda tidak bisa mendapatkan kucing (gen_clust_index). Saya kira inilah mengapa MyISAM terus ada untuk kinerja pembacaannya, kelenturannya dalam pemesanan tabel, format baris tabel, dan alat-alat yang mendukungnya. InnoDB akan tetap dirancang sesuai dengan sifatnya yang sesuai dengan ACID hingga beberapa jiwa pemberani mengambil kode sumber InnoDB dan mengubahnya menjadi sesuatu yang memiliki yang terbaik dari MyISAM dan InnoDB .

The indeks berkerumun mungkin yang alasan untuk kinerja concurrency InnoDB pada putaran drive tradisional.

Mengakses baris melalui indeks berkerumun cepat karena data baris ada di halaman yang sama dengan tempat pencarian indeks. Jika tabel besar, arsitektur indeks berkerumun sering menyimpan operasi I / O disk bila dibandingkan dengan organisasi penyimpanan yang menyimpan data baris menggunakan halaman berbeda dari catatan indeks. (Misalnya, MyISAM menggunakan satu file untuk baris data dan yang lainnya untuk catatan indeks.)

Disk I / O itu mahal. Jadi mengurangi itu adalah manfaat besar untuk meningkatkan konkurensi.

Jika disk I / O mulai menjadi lebih murah dan lebih sedikit hambatan (misalnya, ketika teknologi SSD menjadi lebih stabil), Oracle mungkin memutuskan untuk mengubah cara kerja indeks InnoDB. Lebih besar kemungkinannya akan tetap sama, karena teknologi yang sama akan membuat 'keterbatasan RAM' kurang menjadi masalah.

Jawaban singkat: Tidak.

Cluster InnoDB melalui kunci primer, dan tanpa adanya kunci primer, ia mengambil indeks unik pertama. Dengan tidak adanya indeks unik, itu menciptakan kunci 6 byte tersembunyi untuk pengelompokan.

Ketika Anda memiliki kunci 6 byte tersembunyi, indeks sekunder apa pun merujuk ke kunci ini, bukan petunjuk yang tepat ke lokasi baris (seperti dalam MyISAM), sehingga Anda berakhir dengan traversal kunci sekunder, dan kemudian kunci primer traversal untuk menemukan catatan Anda .

Untuk memperkirakan sedikit dari pertanyaan Anda, saya berasumsi Anda khawatir tentang memori yang cocok dengan pohon, karena untuk mencari secara efisien, semua node root harus ada dalam memori, karena Anda selalu harus berjalan di jalan ini untuk menemukan halaman daun Anda?

Ini benar, tetapi satu penghiburan adalah bahwa database komersial mencoba dan membuat pohon mereka menjadi setinggi mungkin, bukan dalam. Coba jalankan xtrabackup --stats pada data Anda untuk melihatnya. Sebagai contoh:

<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%

Ada 497839 halaman daun (~ 8GB), tetapi hanya 416 halaman di atas (6,5MB). Saya telah menjalankan perintah ini beberapa kali pada data produksi, dan selalu mengejutkan saya ketika saya memiliki jutaan-milyaran catatan, dan hanya level 1-3 halaman + halaman daun.