Tabel Sementara Bukan Halaman di Buffer Pool
Resep yang beredar menyuruh menaikkan satu angka, padahal query WordPress yang berat sering membangun tabel gores yang tidak kamu tulis sendiri. Panduan tmp_table_size wordpress ini meluruskan anggapan itu: batas yang dipakai server belum tentu angka yang kamu naikkan. Kamu akan mendapat tiga hal: batas mana yang menang, cara membaca counter disk, dan kapan menaikkan batas justru memakan RAM.
Tabel gores itu bukan halaman di buffer pool. Buffer pool menyimpan halaman data dan indeks agar query berikutnya tidak membaca disk lagi. Tabel sementara internal justru sebaliknya: MariaDB membangunnya untuk satu pernyataan, memakainya sebentar, lalu membuangnya. Karena sifatnya sekali pakai, batasnya pun dihitung per tabel per pernyataan, bukan per server.
Akibatnya, menaikkan satu angka tanpa tahu pasangan batasnya sering berakhir kecewa: counter disk tetap naik dan tidak ada yang berubah. Tiga bagian pertama artikel ini menunjukkan batas mana yang sebenarnya menang dan query apa yang memicu tabel gores. Setelah itu kamu membaca counter dengan benar dan memutuskan kapan batas boleh naik.
Yang Dipakai adalah Nilai yang Lebih Kecil
Perbandingan tmp_table_size vs max_heap_table_size adalah kunci seluruh artikel ini. Yang pertama membatasi tabel sementara internal yang dibuat server untuk satu pernyataan. Panduan max_heap_table_size wordpress yang benar selalu menyebut pasangannya: variabel kedua membatasi tabel MEMORY buatan pengguna, sekaligus ikut membatasi tabel internal lewat nilai yang lebih kecil.
Dokumentasi MariaDB menulis default 16777216, dengan catatan default bisa berbeda di sebagian sistem, jadi jangan membaca angka itu sebagai nilai server kamu. Cek nilai aktual dengan SHOW VARIABLES di server masing-masing. Alias tmp_memory_table_size merujuk ke variabel yang sama, dan keduanya dinamis untuk global maupun session.
Nilai yang dipakai server adalah yang lebih kecil di antara tmp_table_size dan max_heap_table_size. Menaikkan salah satu saja tidak menggeser batas kalau yang lain masih lebih rendah.
| Variabel | Yang dibatasi | Kalau terlampaui, pada MariaDB |
|---|---|---|
tmp_table_size | Tabel sementara yang dibuat server, di memori | Dikonversi ke Aria kalau ini yang lebih kecil, atau kalau pasangannya sama rendahnya |
max_heap_table_size | Tabel MEMORY buatan pengguna. Ikut membatasi tabel internal lewat nilai yang lebih kecil | CREATE TEMPORARY tidak dikonversi. Server mengembalikan galat bahwa tabel penuh |
Aturannya sederhana: setiap pernyataan mendapat jatah sampai nilai yang lebih rendah, selebihnya pindah ke Aria. Nilai global dan session bisa berbeda, jadi pastikan kamu membaca konteks session yang dipakai aplikasi. Diagram di atas merangkum pasangan batas dan dua ujungnya.
Query WordPress yang Membangun Tabel Gores
Urut dan saring adalah pemicu paling umum. GROUP BY, DISTINCT, dan UNION memaksa server menampung hasil antara sebelum baris final keluar. Makin banyak baris yang harus disortir atau digabung, makin besar tabel gores yang dibutuhkan pernyataan itu. Query kecil yang rapi jarang menyentuh batas ini.
Di WordPress, turunan dari meta_query atau tax_query yang rumit sering menjadi sumbernya. Filter berlapis di katalog produk, arsip dengan banyak taksonomi, dan laporan pesanan dengan rentang tanggal lebar bisa melahirkan gabungan yang berat. Tidak ada satu plugin yang bisa dituding; pola query-nya yang menentukan.
Kadang tabel itu ada karena pernyataan tidak punya indeks yang pas, dan satu kalimat panduannya ada di artikel Indeks Database WordPress. Indeks yang tepat membuat server membaca baris berurutan tanpa menampung hasil antara. Jadi sebelum menyentuh batas, pastikan dulu query-nya sudah dibantu indeks.
Counter Disk yang Kumulatif
Angka created_tmp_disk_tables wordpress yang kamu lihat di monitor adalah hitungan kumulatif sejak server terakhir nyala. Ia hanya naik, tidak pernah turun sendiri, dan tidak mengenal tanggal. Membacanya sebagai laporan hari ini adalah kesalahan pertama yang harus dibuang.
Rasio seumur hidup menipu kalau server sudah berbulan-bulan hidup: satu periode buruk tiga bulan lalu terus mengotori angka sampai sekarang. Sebagai counter lain, Sort_merge_passes dan filesort menyebut kejadian sortir yang lolos ke disk, lalu topik itu ditinggal di sini karena bukan fokus artikel.
Yang jujur adalah selisih dua cuplikan pada jendela keluhan: catat angkanya, ulangi tindakan yang dikeluhkan, baca lagi. Diagram di atas menunjukkan cara itu: dua kartu waktu dikurangi, hasilnya yang dibaca. Kartu rasio sejak server nyala dicoret karena tidak menjawab keluhan hari ini.
Menaikkan Batas Tidak Mereservasi RAM
Memori diambil saat tabel tumbuh, sampai nilai yang lebih kecil, lalu dilepas ketika pernyataan selesai. Batas ini tidak direservasi di muka untuk setiap koneksi yang menganggur. Server yang sepi tetap ramping walau angkanya besar, karena tidak ada tabel gores yang sedang dibangun.
Biaya terburuknya muncul saat beberapa pernyataan besar berjalan bersamaan: masing-masing bisa memegang tabel sampai batas itu pada saat yang sama. Inilah bentuk biayanya, beberapa pernyataan yang masing-masing bisa tumbuh sampai batas, bukan angka tetap per koneksi. Anggaran slot koneksi yang menaungi pernyataan itu dibahas satu kalimat di artikel max_connections WordPress.
Bedakan juga dengan penyimpan halaman data yang melayani banyak query sekaligus, satu kalimatnya ada di artikel InnoDB Buffer Pool WordPress. Buffer pool menampung halaman untuk dipakai ulang, sedangkan batas ini menampung goresan sekali pakai. Menaikkan yang satu tidak mengisi yang lain.
Aria untuk yang Internal, Galat untuk yang Dibuat Sendiri
Pada MariaDB, tabel sementara internal yang melewati batas dikonversi ke Aria. Mesin Aria menulisnya ke direktori tmpdir, sehingga pernyataan tetap selesai walau lebih lambat dari memori. Konversi ini otomatis dan tidak meminta izin, jadi satu-satunya tandanya adalah counter disk yang naik.
Nasib berbeda menanti tabel yang dibuat lewat CREATE TEMPORARY. Tabel buatan sendiri tidak dikonversi ke Aria; ketika penuh, server mengembalikan galat bahwa tabel penuh dan pernyataan berhenti. Keduanya sama-sama disebut tabel sementara, tetapi perlakunya berlawanan.
Direktori tmpdir yang penuh adalah gejala berbeda dari batas yang kecil: yang satu soal ruang disk, yang satu soal ambang konversi. Satu kalimat pembeda: MySQL 8 tidak mengikuti jalur ini karena memakai mesin TempTable dengan temptable_max_ram sebagai pengaturnya.
Perbaiki Pernyataan Sebelum Menaikkan Angka
Kalau selisih disk naik hanya pada satu laporan atau satu layar admin, pernyataannya yang mahal. Satu layar itu menjalankan query yang sama setiap dibuka, sehingga polanya mudah diulang dan mudah diukur. Tangkap SQL-nya, baca di artikel Slow Query Log WordPress, lalu sederhanakan saringan atau pecah laporannya.
Menaikkan batas untuk kasus seperti itu hanya menutupi gejala dan memperbesar RAM terburuk. Tabel gores yang tadinya pindah ke disk kini bertahan di memori, dan beberapa laporan bersamaan bisa memegangnya sekaligus. Angka yang besar tanpa query yang rapi adalah janji RAM yang belum ditagih.
Cara Membaca Selisih Created_tmp_disk_tables
Urutannya tetap: catat kedua variabel, ambil dua cuplikan pada jendela keluhan, baru putuskan cabang. Jangan melompat ke kesimpulan sebelum ketiga langkah ini selesai, karena angka mentah created_tmp_disk_tables wordpress tanpa jendela waktu tidak menjawab apa-apa.
Catat Kedua Variabel, Lalu yang Lebih Kecil
Baca tmp_table_size dan max_heap_table_size wordpress dengan SHOW VARIABLES pada session yang dipakai aplikasi. Bandingkan keduanya dan pegang nilai yang lebih rendah sebagai batas efektif. Cuplikan berikut hanya ilustrasi bentuknya:
-- Ilustrasi: baca kedua variabel, yang lebih kecil yang dipakai.
SHOW VARIABLES WHERE Variable_name IN ('tmp_table_size', 'max_heap_table_size');Nilai global dan session bisa berbeda, jadi angka di konfigurasi belum tentu angka yang dipakai query-mu. Kalau situsmu di Cloud Hosting, jangan mengubah pengaturan database; cukup catat kedua nilai sebagai bahan diskusi dengan tim teknis.
Dua Cuplikan pada Jendela yang Sama
Baca SHOW GLOBAL STATUS untuk Created_tmp_tables dan Created_tmp_disk_tables, catat jamnya. Ulangi tindakan yang dikeluhkan, misalnya buka layar laporan yang lambat, lalu baca kedua counter lagi. Kurangi angka kedua dengan angka pertama: selisih itulah yang dibaca, bukan angka mentah.
Cuplikan kemarin tidak menjelaskan keluhan siang ini, karena trafik dan query-nya sudah berbeda. Selisih nol pada jendela itu berarti tabel sementara bukan penyebabnya, walau angka totalnya terlihat besar. Lanjutkan diagnosis ke arah lain.
Pilih Cabang: Batas, Query, atau Kapasitas
Tiga cabang sesuai tabel berikut. Jangan menaikkan batas kalau selisih disk nol pada jendela itu, karena tidak ada tabel gores yang perlu ditampung. Tabel ini merangkum keputusan, tanpa mengulang isi artikel rujukan.
| Yang terlihat pada jendela keluhan | Langkah berikut | Bukan langkah pertamanya |
|---|---|---|
| Selisih disk naik bersama satu layar laporan atau admin | Baca pernyataan itu di slow query log | Menaikkan batas sampai RAM sesak |
| Kedua variabel berbeda jauh | Samakan dulu pemahaman ke nilai yang lebih kecil, baru putuskan apakah nilai itu memang sengaja | Menaikkan hanya tmp_table_size |
| Banyak pernyataan besar berjalan bersamaan | Lihat anggaran koneksi sebelum memperbesar batas per pernyataan | Menganggap memori gores ini gratis |
Cabang yang benar menghemat jam kerja. Cabang yang salah, menaikkan batas untuk masalah query atau mematikan fitur untuk masalah kapasitas, membuang jam itu.
Di Hosting Mana Variabel Ini Bisa Diubah
Di Cloud Hosting Mordenhost, gejala query seperti ini bisa dibantu tim teknis saat kamu melaporkan layar mana yang lambat dan kapan terjadinya. Akses berkas konfigurasi database tidak termasuk di sini, jadi yang bisa dilihat dari WordPress hanyalah gejala query. Kamu fokus mengelola toko, tim teknis membaca gejalanya.
Tim yang perlu mengubah kedua variabel setelah selisih counter dibaca butuh akses server. Managed VPS Mordenhost cocok untuk kasus ini, mulai Rp950.000 per bulan: kedua variabel bisa diubah berdampingan dengan anggaran koneksi. Fondasi cara server bekerja dijelaskan ringkas di artikel memahami cara kerja hosting.
Pertanyaan yang Sering Ditanya
Empat jawaban singkat soal batas yang menang, counter yang tinggi, beda dengan buffer pool, dan akses di Cloud Hosting.
Apakah menaikkan tmp_table_size selalu mengurangi tabel di disk?
Tidak selalu. Batas yang dipakai adalah yang lebih kecil di antara dua variabel itu. Counter disk juga naik karena tabel yang dari awal tidak muat di memori, bukan hanya karena batasnya terlalu rendah.
Apakah Created_tmp_disk_tables yang tinggi berarti situs rusak?
Belum tentu. Angkanya kumulatif sejak server nyala, jadi rasio lama tidak menggambarkan hari ini. Bandingkan selisihnya pada jendela yang sama dengan keluhan, baru putuskan apakah batas atau query yang perlu diubah.
Apakah tmp_table_size sama dengan innodb_buffer_pool_size?
Tidak. Buffer pool menyimpan halaman data dan indeks InnoDB untuk banyak query. tmp_table_size membatasi satu tabel sementara di memori untuk satu pernyataan. Menaikkan yang satu tidak mengisi yang lain.
Apakah Cloud Hosting bisa mengubah tmp_table_size?
Tidak lewat berkas konfigurasi database. Yang bisa dilihat dari WordPress hanyalah gejala query. Mengubah variabel ini butuh akses server, dan itu masuk ke Managed VPS, bukan ke panel hosting bersama.
Butuh bantuan membaca counter atau memilih paket yang pas? Hubungi WhatsApp Mordenhost dan tim kami membantu memetakan langkah berikutnya.
