Mengapa MySQL menghasilkan banyak file MYD sementara?


9

Pada server Linux Debian, hosting banyak situs web PHP / MySQL (galeri foto), kadang-kadang saya memiliki "banyak" file seperti /tmp/#sql_6405_58.MYD.

Misalnya hari ini:

[2012-12-15 15:18:11] /tmp/#sql_6405_6.MYD : 88MB
[2012-12-15 15:18:11] /tmp/#sql_6405_3.MYD : 22MB
[2012-12-15 15:18:11] /tmp/#sql_6405_4.MYD : 138MB
[2012-12-15 15:18:11] /tmp/#sql_6405_10.MYD : 88MB
...
[2012-12-15 15:18:11] /tmp/#sql_6405_9.MYD : 15MB
[2012-12-15 15:18:11] /tmp/#sql_6405_65.MYD : 49MB
[2012-12-15 15:18:11] /tmp/#sql_6405_44.MYD : 69MB

(59 file pada saat bersamaan, lebih dari 6GB ... ya saya memonitor file besar di / tmp)

Sayangnya, /tmpada di partisi yang sama /dan sementara itu merusak server web, karena /penuh saya kira. Kemudian file hilang dan server kembali normal.

Semua nama file mengikuti #sql_6405_*.MYDpola. Saya ingin memahami operasi MySQL mana yang menyiratkan begitu banyak file sementara. Saya memiliki sekitar 2000 database di server ini. Apakah mungkin untuk mengetahui basis data yang bersangkutan?


1
Saya menduga mereka adalah data temp untuk operasi besar yang digunakan filesort, dan 6405 adalah PID dari mysql untuk menyimpan file temp dari berbagai server yang terpisah.

Haruskah saya meminta admin untuk memindahkan pertanyaan saya?

Jawaban:


14

Ada beberapa opsi yang dapat menyebabkan tabel temp terwujud sebagai tabel MyISAM atau dapat dikonfigurasi untuk menunda itu. Perlu diingat bahwa untuk tabel temp berbasis disk, tidak ada .frmfile, tapi hanya .MYDdan .MYIfile (tentu saja. File MYI tidak pernah digunakan karena tidak mungkin indeks tabel suhu internal).

Berikut ini opsinya:

Anda juga harus mempertimbangkan Dokumentasi MySQL tentang Penggunaan Tabel Temp Internal

Situasi di mana tabel temp di memori dibuat

  • Jika ada klausa ORDER BY dan klausa GROUP BY berbeda, atau jika ORDER BY atau GROUP BY berisi kolom dari tabel selain dari tabel pertama dalam antrian bergabung, tabel sementara dibuat.
  • DISTINCT dikombinasikan dengan ORDER BY mungkin memerlukan tabel sementara.
  • Jika Anda menggunakan opsi SQL_SMALL_RESULT, MySQL menggunakan tabel sementara di dalam memori, kecuali kueri juga berisi elemen (dijelaskan nanti) yang memerlukan penyimpanan di-disk.

Ketika tabel temp di dalam memori melebihi minimum (tmp_table_size atau max_heap_table_size), mysqld melakukan hal berikut:

  • Tangguhkan kueri
  • Menyalin isi tabel di memori ke tabel temp MyISAM
  • Buang tabel di dalam memori
  • Melanjutkan kueri, mengirimkan data temp ke dalam tabel temp MyISAM

Situasi di mana tabel temp di-memori dilewati demi disk adalah

  • Kehadiran kolom BLOB atau TEXT dalam tabel
  • Kehadiran kolom apa pun dalam klausa GROUP BY atau DISTINCT lebih besar dari 512 byte
  • Kehadiran kolom apa pun yang lebih besar dari 512 byte dalam daftar SELECT, jika UNION atau UNION ALL digunakan

Diperlukan beberapa uji tuntas untuk mengurangi pembuatan tabel temp pada disk

  • Pengaturan join_buffer_size lebih besar
  • Pengaturan sort_buffer_size lebih besar
  • Pengaturan tmp_table_size dan max_heap_table_size lebih besar
  • Menyetel kueri untuk meminimalkan atau bahkan mencegah tabel temp
  • Membuat indeks untuk membuat tampilan data dari tabel individual
  • Menginstal RAM tambahan untuk mengakomodasi tabel temp dalam memori yang besar

Jika setelah uji tuntas semacam itu, masih ada tabel temp yang sedang dibentuk pada Disk, berikut ini adalah satu langkah putus asa: Memetakan pembuatan tabel temp berbasis disk ke memori.

Berikut adalah cara cepat dan kotor untuk mengatur Disk RAM 16GB menggunakan tmpdir

STEP01) Buat Folder Disk RAM

mkdir /var/mysql_tmpfs

LANGKAH02) Tambahkan ini ke my.cnf

[mysqld]
tmpdir=/var/mysql_tmpfs

LANGKAH03) Tambahkan ini ke / etc / fstab

echo "none /var/mysql_tmpfs tmpfs defaults,size=16g 1 2" >> /etc/fstab

LANGKAH04) Muat ulang / etc / fstab

mount -a

LANGKAH05) service mysql restart

Setelah ini, semua tabel temp yang menjadi MyISAM ditulis ke RAM Disk. Ini akan mempercepat pembuatan tabel temp berbasis disk.

Cobalah !!!


1

Ini adalah pertanyaan yang berguling ke disk karena hasilnya terlalu besar untuk memori.

Saat kueri selesai, ruang kosong.

Tidak ada cara untuk mencocokkan file temp ini secara definitif dengan kueri, tetapi Anda bisa mendapatkan petunjuk untuk membuat tebakan yang baik dari SHOW FULL PROCESSLIST; atau TAMPILKAN STATUS INNODB; atau dengan melihat log kesalahan Anda jika kueri gagal.


1

Setiap kali kita menggunakan pernyataan alter di atas tabel itu menciptakan file temporay # sql_6405_3.MYD dan setelah selesai melempar output dan menghilang.

Mengubah pada tabel membuat MySQL untuk menyalin seluruh data menjadi file sementara # sql.xxx.MYD dan membuat perubahan pada file sementara yang dibuat kemudian drop file data asli tablename.MYD dan mengganti nama file temporay ke nama tabel.

Juga untuk beberapa permintaan penyortiran agak itu membuat file sementara.

Saat saya ditelusuri. Hal ini terjadi.


0

Saya pikir Anda mungkin menemukan pertanyaan dalam log permintaan lambat, karena pertanyaan yang membuat tabel temp besar biasanya berjalan untuk waktu yang lama, ini adalah bagaimana hal itu membantu saya hari ini di server di mana saya menemukan /tmppartisi penuh karena mirip file temp MySQL besar, itu file 4G, saya menemukan permintaan pada log permintaan lambat dan melaporkan permintaan kepada pengembang dan mereka menemukan korupsi pada permintaan dan mereka akan memperbaikinya, tampaknya danau untuk batas instruksi MySQL sehingga berlari untuk waktu yang lama dan menulis file temp 4G dan mengisi /tmppartisi.

Dan ada cara lain Anda dapat menemukan apa yang menyebabkan file temp besar ini, ini biner sehingga Anda tidak dapat membacanya secara langsung tetapi saya menemukan Anda dapat melihat teks yang berisi itu dengan menggunakan perintah Linux strings seperti ini,

strings name-of-mysql-temp-file

Saya memastikan dari kata-kata teks apa query MySQL berjalan dan menciptakannya.

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.