MySQL и MariaDB LinuxMySQL 8.0/8.4Percona Server 8.0/8.4

MySQL: растёт ibtmp1 при запросах с временными таблицами

  • Обновлено
  • Чтение ≈ 4 минуты

Краткий ответ

Нужно отличить рабочее пространство InnoDB от временных файлов операционной системы и выяснить запрос, который создаёт большие промежуточные результаты. Освобождённое пространство ibtmp1 может повторно использоваться, даже если размер файла не уменьшается.

В этой статье
  1. Что означает неисправность и в каких условиях возникает
  2. Возможные причины: как различить
  3. Пошаговая диагностика и устранение
  4. Как проверить исправление и что делать, если оно не помогло

#Что означает неисправность и в каких условиях возникает

Файл ibtmp1 в каталоге данных MySQL/Percona увеличивается при сортировках и временных таблицах, иногда занимая десятки гигабайт. Для InnoDB это глобальное временное табличное пространство; его нельзя удалять вручную при работающем сервере. Нужно отличить рабочее пространство InnoDB от временных файлов операционной системы и выяснить запрос, который создаёт большие промежуточные результаты. Освобождённое пространство ibtmp1 может повторно использоваться, даже если размер файла не уменьшается.

#Возможные причины: как различить

Возможная причинаКак узнатьЧто делать
Большие временные результаты запросовJOIN, GROUP BY, ORDER BY и пользовательские временные таблицы приводят к записи на диск.Рост совпадает с выполнением тяжёлого отчёта или импорта.Проверить план запроса и сокращение промежуточного набора.
Много параллельных временных таблицНесколько копий отчёта выполняются одновременно.Количество активных запросов и нагрузка растут вместе с ibtmp1.Ограничить параллельность фоновых задач.
Обычное повторное использование файлаПосле завершения запроса файл остаётся большим на диске.Процессы закончились, но ibtmp1 не уменьшился; в свободных страницах возможна повторная запись.Планировать обслуживание и следить за свободным местом, не удалять файл.

#Пошаговая диагностика и устранение

  1. Убедитесь, что найден именно ibtmp1Подключитесь по SSH к серверу MySQL. В клиенте mysql выполните SHOW VARIABLES LIKE 'datadir'; и SHOW VARIABLES LIKE 'innodb_temp_data_file_path';. Сопоставьте каталог данных и путь к файлу. Не полагайтесь на путь /var/lib/mysql/ibtmp1 по умолчанию: на конкретном сервере каталог может отличаться.
  2. Измерьте свободное место без измененийНа Linux откройте терминал и запустите df -h для файловой системы базы и du -h для конкретного файла, если у вас есть доступ. Сохраните значения и сравните через 10–15 минут; если свободного места осталось критически мало, сообщите администратору сразу. Не переносите файл на лету и не создавайте символьную ссылку без согласованной процедуры.
  3. Сопоставьте рост с запросамиВ административной сессии SHOW FULL PROCESSLIST; покажет активные запросы. Найдите долгие операции с Using temporary/Using filesort по EXPLAIN и временем отчёта. Не считайте все SELECT причиной: требуется совпадение по времени и объёму. Если право PROCESS недоступно, попросите DBA собирать диагностику вместо повышения прав учётной записи сайта.
  4. Проверьте показатели временных таблицВ mysql выполните SHOW GLOBAL STATUS LIKE 'Created_tmp%';, запишите значения с временем и повторите во время отчёта. Created_tmp_disk_tables — накопительный счётчик с момента запуска и не даёт прямого размера ibtmp1. По изменению счётчиков и времени запроса определяйте, когда растёт потребность во временных структурах.
  5. Найдите тяжёлый SQL и проверьте планНа копии данных используйте EXPLAIN для SELECT из отчёта. Определите большие промежуточные выборки, отсутствие ограничений WHERE и дорогие GROUP BY/ORDER BY. Сначала уменьшите объём данных и добавьте обоснованный индекс в тестовой среде; не увеличивайте без расчёта tmp_table_size или max_heap_table_size на рабочем сервере.
  6. Проверьте, освобождается ли рабочее пространствоДождитесь завершения тяжёлого запроса и попробуйте повторить операцию сопоставимого размера в контролируемом тестовом окне; файл может не расти дальше, поскольку использует уже выделенные страницы. Само отсутствие уменьшения размера не означает утечку данных и не требует аварийного рестарта.
  7. Планируйте уменьшение файла только при необходимостиЕсли большой ibtmp1 мешает ёмкости диска, согласуйте штатную остановку и запуск MySQL в окно обслуживания после полной резервной копии и оценки репликации. Глобальное временное табличное пространство создаётся при запуске заново, однако рестарт прерывает все соединения. Запрещено удалять ibtmp1 вручную у работающего процесса mysqld.
  8. Ограничьте дальнейший рост через нагрузкуПосле оптимизации запросов проверьте расписание отчётов и число одновременных процессов, чтобы временные объекты не создавались одновременно. При каждом изменении сохраните прежние настройки планировщика и повторите тест. Если рост повторяется, соберите имена запросов и график размера файла, а не пытайтесь циклически перезапускать базу.
  9. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
    Выберите подходящий вариант — это не команды для последовательного выполнения
    Вариант 1SQL для чтения конфигурации и накопленных счётчиков; актуальное имя переменной зависит от сборки.
    SQLКоманда
    SQL для чтения конфигурации и накопленных счётчиков; актуальное имя переменной зависит от сборки.
    SHOW VARIABLES LIKE 'datadir';
    SHOW VARIABLES LIKE 'innodb_temp_data_file_path';
    SHOW GLOBAL STATUS LIKE 'Created_tmp%';
    Вариант 2Выполнить в терминале Linux для просмотра свободного места; никаких файлов не меняет.
    Linux · Терминал (Bash)Только проверка
    Выполнить в терминале Linux для просмотра свободного места; никаких файлов не меняет.
    df -h

#Как проверить исправление и что делать, если оно не помогло

Успех — после оптимизации крупного отчёта рост ibtmp1 останавливается или становится прогнозируемым, файловая система имеет запас места, запросы выполняются быстрее. Если размер стабилен, а места достаточно, срочное уменьшение не нужно; запланируйте обслуживание, если объём действительно мешает работе.

Так эту ошибку тоже называют

MySQL: ERROR 1045 (28000) Access denied for user — причины и решение Проверьте пароль, хост пользователя и привилегии. Программирование и базы данных MySQL и MariaDB LinuxWindowsmacOS MySQL: ERROR 2002 — Can't connect through socket — причины и решение Запустите mysqld и проверьте путь сокета. Программирование и базы данных MySQL и MariaDB LinuxWindowsmacOS 1045 MySQL ERROR 1045 (28000): Access denied for user — как исправить `ERROR 1045 (28000): Access denied for user` значит, что сервер MySQL отклонил вход: неверный пароль, пользователь не существует для этого хоста, у него нет прав или исп… Программирование и базы данных MySQL и MariaDB MySQLMariaDB 1064 MySQL: ERROR 1064 — You have an error in your SQL syntax — причины и решение Ошибка 1064 — синтаксическая ошибка в запросе. Ниже — причины и порядок действий от простого к сложному. Программирование и базы данных MySQL и MariaDB LinuxWindows 1146 MySQL: ERROR 1146 — Table doesn't exist — причины и решение Таблица не найдена: неверная база, регистр имени в Linux или не применены миграции. Проверьте USE и SHOW TABLES. Программирование и базы данных MySQL и MariaDB LinuxWindowsmacOS

Источники и обновления

Последнее обновление статьи: 2 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.