Назад | Перейти на главную страницу

MySQL не может создать / записать в файл

После того, как MySQL проработал какое-то время (обычно 4-6 часов), некоторые более крупные и более загруженные запросы постоянно (до перезапуска) не работают, возвращая следующую ошибку:

Can't create/write to file '#sql_75ed_0.MYD' (Errcode: 17)

Поиск в Google этой ошибки возвращает множество вероятных причин, но я считаю, что ее можно разрешить двумя простыми способами;

1) Оптимизируйте запросы. (Хорошее решение на длительный срок.)

2) Каким-то образом настроить конфигурацию MySQL. (Это то, что я хочу сделать)

В свете вопроса, вот наши текущие нестандартные значения в my.cnf:

query_cache_size = 8M
query_cache_limit = 8M

thread_cache_size = 4
max_connections = 90
table_cache = 4096
innodb_buffer_pool_size = 900M

tmp_table_size = 512M
max_heap_table_size = 256M

innodb_file_per_table

Я склонен полагать, что мы можем заметить значительный прирост производительности при дальнейшей настройке этих переменных, но это вопрос, ожидающий ответа позже.

Вот пример запроса, который начинает давать сбой:

SELECT DISTINCT u.user_id, u.username, u.username_clean, u.user_colour, MAX(s.session_time) as online_time, MIN(s.session_viewonline) AS viewonline FROM (table_users u, table_zebra z) LEFT JOIN table_sessions s ON (s.session_user_id = z.zebra_id) WHERE z.user_id = 4 AND z.friend = 1 AND u.user_id = z.zebra_id GROUP BY z.zebra_id, u.user_id, u.username_clean, u.user_colour, u.username ORDER BY u.username_clean ASC

Результат EXPLAIN вышеуказанного запроса возвращает следующее:

1, 'SIMPLE', 'z', 'ref', 'PRIMARY,zebra_id_friend', 'PRIMARY', '3', 'const', 18, 'Using where; Using temporary; Using filesort'
1, 'SIMPLE', 's', 'ref', 'session_user_id', 'session_user_id', '3', 'database_name.z.zebra_id', 402, ''
1, 'SIMPLE', 'u', 'eq_ref', 'PRIMARY', 'PRIMARY', '3', 'database_name.z.zebra_id', 1, ''

Любая помощь будет оценена!

MySQL создает временные файлы в определенных ситуациях для обработки результатов запроса. Одна из распространенных ситуаций, когда это происходит, - это когда сортировка происходит с данными столбца, имеющими тип текста или большого двоичного объекта. Другие включают, когда исчерпан максимально допустимый размер временной таблицы.

Создание этих таблиц указывает на запросы, которые не могут быть полностью оптимизированы, но в некоторых случаях их невозможно избежать. Однако вы не должны получать ошибок (в некоторых производственных средах, с которыми я работаю, десятки из них могут создаваться каждую минуту).

Обычно файлы создаются в / tmp. Вы можете наблюдать за этим каталогом и видеть, как они создаются и уничтожаются. Если / tmp или какой-либо другой каталог не может быть записан пользователем mysql, возможно, это ваша проблема.

В противном случае поищите более приземленные проблемы, например, нехватку места на диске.

Вот некоторая дополнительная информация из документации MySQL.

Это довольно неясно, но я думаю, что у вас может (просто может быть) быть куча мертвых временных таблиц SQL, таких как та, которая висит вокруг, и в конечном итоге mysqld пытается повторно использовать то же имя файла и терпит неудачу, потому что у него есть внутренние правила, говорящие ему никогда не перезаписывать .MYD.

Я бы порекомендовал посмотреть, где эти #sql_XXXX_X.MYD файлы работают, выключите mysqld, очистите временные файлы и перезапустите его.

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