Почему MySQL создает так много временных файлов MYD?

На сервере Debian Linux, на котором размещено много сайтов PHP / MySQL (фотогалереи), иногда у меня есть «много» файлов вроде /tmp/#sql_6405_58.MYD.

Например сегодня:

[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 файлов одновременно, для более чем 6 ГБ ... да, я отслеживаю большие файлы в / tmp)

К сожалению, /tmpнаходится на том же разделе, что /и временно нарушает работу веб-сервера, потому что, /я полагаю, заполнен. Затем файлы исчезают, и сервер возвращается в нормальное состояние.

Все имена файлов следуют #sql_6405_*.MYDшаблону. Я хотел бы понять, какая операция MySQL подразумевает так много временных файлов. У меня есть около 2000 баз данных на этом сервере. Можно ли узнать, какая база данных касается?

Существуют некоторые параметры, которые могут привести к тому, что временные таблицы материализуются как таблицы MyISAM или могут быть настроены на задержку. Имейте в виде , что для дисковых временных таблиц, нет никаких .frmфайлов, но только .MYDи .MYIфайлов (конечно. Файл .MYI никогда не используется , так как невозможно индекс внутренней таблицы температуры).

Вот варианты:

• Переменные таблицы Temp, которые должны быть одинакового размера
  • tmp_table_size
  • max_heap_table_size
• sort_buffer_size
• join_buffer_size

Вы должны также рассмотреть документацию MySQL по использованию внутренней временной таблицы

Ситуации, когда создаются временные таблицы в памяти:

• Если есть предложение ORDER BY и другое предложение GROUP BY, или если ORDER BY или GROUP BY содержит столбцы из таблиц, отличных от первой таблицы в очереди соединения, создается временная таблица.
• DISTINCT в сочетании с ORDER BY может потребовать временную таблицу.
• Если вы используете опцию SQL_SMALL_RESULT, MySQL использует временную таблицу в памяти, если только запрос не содержит элементов (описанных ниже), которые требуют хранения на диске.

Когда временная таблица в памяти превысила минимум (tmp_table_size или max_heap_table_size), mysqld делает следующее:

• Приостанавливает запрос
• Копирует содержимое таблицы в памяти в временную таблицу MyISAM
• Сбрасывает таблицу в памяти
• Продолжает запрос, отправляя временные данные в временную таблицу MyISAM

Ситуации, когда временные таблицы в памяти игнорируются в пользу диска,

• Наличие столбца BLOB или TEXT в таблице
• Наличие любого столбца в предложении GROUP BY или DISTINCT размером более 512 байт.
• Наличие любого столбца размером более 512 байт в списке SELECT, если используется UNION или UNION ALL

Требуется некоторая должная осмотрительность, чтобы уменьшить создание временной таблицы на диске

• Установка join_buffer_size больше
• Установка sort_buffer_size больше
• Установка tmp_table_size и max_heap_table_size больше
• Настройка запросов для минимизации или даже предотвращения временных таблиц
• Создание индексов для создания предварительно отсортированного представления данных из отдельных таблиц
• Установка дополнительной оперативной памяти для размещения больших временных таблиц в памяти

Если после такой должной осмотрительности все еще создаются временные таблицы на диске, вот один отчаянный шаг: отображение создания временной таблицы на диске в память.

Вот быстрый и грязный способ установки 16 ГБ RAM-диска с помощью tmpdir

STEP01) Создать папку на диске RAM

mkdir /var/mysql_tmpfs

STEP02) Добавить это к my.cnf

[mysqld]
tmpdir=/var/mysql_tmpfs

STEP03) Добавьте это в / etc / fstab

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

STEP04) Перезагрузите / etc / fstab

mount -a

версии STEP05) service mysql restart

После этого все временные таблицы, которые становятся MyISAM, записываются на RAM-диск. Это должно ускорить создание временной таблицы на диске.

Попробуйте!

Это запросы, которые переносятся на диск, потому что результаты слишком велики для памяти.

Когда запрос выполнен, пространство очищается.

Нет никакого способа точно сопоставить эти временные файлы с запросами, но вы можете получить подсказки, чтобы сделать правильное предположение из SHOW FULL PROCESSLIST; или ПОКАЗАТЬ ИННОДБ СТАТУС; или, заглянув в журнал ошибок, если запросы не пройдены.

Всякий раз, когда мы используем операторы alter для таблицы, он создает временные файлы # sql_6405_3.MYD, а по окончании выдает результат и исчезает.

Изменение таблиц заставляет MySQL копировать целые данные во временные файлы # sql.xxx.MYD и вносить изменения в созданные временные файлы, а затем удалять исходные файлы данных tablename.MYD и переименовывать временные файлы в имя таблицы.

Также для некоторых запросов сортировки создаются временные файлы.

Как я проследил. Это случается.

Я думаю, что вы можете найти рассматриваемые запросы в медленном журнале запросов, так как запросы, которые создают большие временные таблицы, обычно выполняются в течение длительного времени, вот как это помогло мне сегодня на сервере, где я обнаружил, что /tmpраздел заполнен из-за подобного большой временный файл MySQL, это был файл 4G, я нашел запрос в журнале медленных запросов и сообщил о запросе разработчикам, и они нашли повреждение в запросе, и они исправят его. долгое время писал 4G временный файл и заполнял /tmpраздел.

И есть еще один способ, с помощью которого вы можете найти причину этого большого временного файла, он является двоичным, поэтому вы не можете прочитать его напрямую, но я обнаружил, что вы можете найти содержащийся в нем текст с помощью команды Linux для строк, например,

strings name-of-mysql-temp-file

По текстовым словам я убедился, что запрос MySQL запустился и создал его.