Kenapa tabel `wp_options` tidak memiliki indeks pada` autoload`?


15

Di awal setiap halaman yang dilayani oleh WordPress, ada panggilan MySQL untuk mengambil opsi:

SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';

Karena tidak ada indeks pada autoloadkolom, MySQL harus mencari SEMUA baris.

Saya juga menemukan komentar dari jawaban ini yang mengatakan tidak akan ada peningkatan kinerja bahkan jika ada indeks.

Dalam aplikasi saya, saya menggunakan banyak nilai sementara untuk dijadikan pengganti sesi. Mereka bekerja dengan sangat baik dan saya memiliki rutinitas pengumpulan sampah sendiri. Saya perhatikan bahwa di wp_optionstabel, nilai sementara saya (yang dimulai dengan _transient_) semua miliki autoload=no. Saya berharap jumlah baris wp_optionstabel saya meningkat seiring dengan meningkatnya jumlah pengguna secara bersamaan.

Saya ingin tahu mengapa meja dirancang dengan cara ini. Dan haruskah saya membuat indeks untuk kasus khusus saya?

Jawaban:


11

Tidak ada indeks karena kebutuhan untuk itu tidak pernah cukup kuat.

Dalam tiket # 14258 disarankan, tetapi karena sebagian besar opsi digunakanautoload=yes secara default, indeks akan diabaikan.

Ada juga tiket yang masih terbuka # 24044 _Tambahkan indeks ke wp_options untuk membantu / meningkatkan kinerja_ .

Saya pikir Anda harus membuat indeks. Ini akan bertahan dari peningkatan. Ini mungkin tidak membantu kinerja Anda, tetapi Anda dapat menambahkan data statistik nyata ke tiket itu.


Perbarui November 2019

Indeks telah ditambahkan ke WordPress 5.3. Akhirnya. Lihat tiket # 24044 yang disebutkan di atas dan catatan pengembang untuk rilis .

Perhatikan bahwa jika Anda memiliki indeks yang ada dengan nama yang sama, Anda akan mendapatkan peringatan selama peningkatan.

Dari setelan perubahan :

Sebagian besar situs tidak akan terpengaruh oleh perubahan ini, tetapi mereka yang memiliki banyak baris wp_options, hanya sejumlah kecil yang telah autoloadditetapkan, akan melihat peningkatan kinerja yang signifikan.
Situs dengan sejumlah besar baris wp_options, dengan banyak dari mereka yang telah autoloadditetapkan sayangnya akan melihat penalti kinerja di atas kueri yang sudah sangat lambat mereka jalankan, tetapi ini harus menjadi minoritas kasus.


1
Sejauh yang saya tahu dari membaca # 24044, tabel MyISAM lama akan mendapatkan regresi kinerja, tabel InnoDB baru sebagian besar akan mendapat manfaat. Saya mengonversi semua tabel lawas saya ke InnoDB, dan menetapkan indeks pada autoloadkolom.
lkraav

Setelah bertahun-tahun, akhirnya ditangani oleh tim WordPress. Indeks telah ditambahkan kewp_options.autoload . Sumber: make.wordpress.org/core/2019/10/15/… ... dan ... core.trac.wordpress.org/ticket/24044#comment:87 ... Kudos kepada @DanBUK yang mengusulkan fitur ini pada 2013.
Astaga

Terima kasih, @ Ya ampun, saya telah memperbarui jawabannya.
fuxia

5

Saya menjalankan 3 WP blog pada contoh besar Debian Squeeze dan sedang menyelidiki mengapa mysql macet di host itu pada penggunaan CPU 200% dan beban sistem antara 3 dan 6. Melihat pada 'tampilkan proses daftar' di dalam mysql, kami memahami tabel wp_option terlibat dalam masalah ini sehingga kami mengeksekusi:

alter table wp_options add index autoload_idx(`autoload`);

Setelah operasi ini, beban mysql seperti yang ditunjukkan di atas turun drastis menjadi 1% dan rata-rata beban contoh sekarang 0,10.

Kami menggunakan beberapa plugin sehingga mungkin ada loop di suatu tempat dalam kode, dan ini mungkin situasi tertentu, tetapi dalam kasus kami perubahan kinerja sangat mencengangkan.

Tabel wp_options kami memiliki 347 baris.


2
Terima kasih telah berbagi. Saya pikir WordPress memang memiliki cacat dalam menangani tabel opsi ini. Ini sangat kecil, sehingga seharusnya tidak meminta. Itu harus select *sekali untuk semua. Alih-alih, meminta setiap opsi, itu sebabnya menempatkan indeks akan membuat perbedaan besar.
He Shiming

0

Sementara @fuxia menerima jawaban yang menyentuh pada beberapa alasan "diklaim" (sebagian besar diklaim oleh karyawan Automattic pada berbagai tiket Trac, dll), alasan mendasar untuk WordPress Core tidak termasuk indeks untuk opsi pengisian otomatis di dalam wp_optionstabel adalah bahwa Automattic khawatir itu akan berdampak negatif terhadap kinerja database MySQL yang masih menggunakan mesin MyISAM.

Secara khusus, mereka menunjuk ke situs web WordPress.org itu sendiri, sebagai database yang sangat lama / kompleks, sebagai contoh situs web yang kinerjanya akan dirugikan oleh indeks semacam itu.

Hampir semua alasan lain untuk tidak menambahkan indeks selama 9 tahun terakhir (ya, sejak 2010 dalam kasus tiket Trac # 14258 dan sejak 2013 dalam kasus tiket Trac # 24044 ) berulang kali terbukti salah oleh puluhan anggota Komunitas WordPress, namun karyawan Automattic yang terlibat berulang kali mengabaikan beberapa tes tolok ukur independen dan kembali ke menyebutkan masalah MyISAM.

Untungnya, pada akhir 2019 dengan PHP 7.2 sekarang versi "default" yang direkomendasikan oleh WordPress Core, dan dengan mesin InnoDB sekarang menjadi default di versi MySQL setelah 5.5 , dan dengan tekanan terus menerus dari berbagai pengembang termasuk @DanBUK yang tetap pada masalah selama bertahun-tahun , Automattic akhirnya menyerah dan memutuskan untuk menambahkan indeks autoload pada WordPress 5.3+ pada November 2019.

Kami di LittleBizzy telah meluncurkan plugin yang dikenal pertama yang secara otomatis menambahkan indeks jika tidak ada, yang masih tersedia di GitHub dan sedang diunduh secara teratur. Harap dicatat bahwa Anda TIDAK LAMA perlu menginstal plugin seperti itu ke tumpukan WordPress Anda jika Anda menjalankan WP Core 5.3 + ...

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.