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

MySQL - изменить столбец таблицы против mysqldump + загрузить данные в файл

У меня большая таблица (~ 250 Гб), и я хочу изменить столбец первичного ключа с INT к BIGINT. Предполагая, что у экземпляра сервера достаточно ресурсов для оптимальной настройки MySQL для обоих методов, какой метод будет выполняться за наименьшее количество времени? 1. Изменить таблицу 2. Создание новой таблицы, экспорт старой с помощью mysqldump и вставив в новый с LOAD DATA INFILE.

Заметка: Я в курсе pt-online-schema-change, что, вероятно, является лучшим вариантом для изменения таблицы, не влияя на использование существующей БД, но я хотел бы знать, какой вариант требует меньше всего времени для запуска.

Бонус: Я подозреваю, что ответ одинаков и для MySQL, и для MariaDB?

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

Дамп и перезагрузка могут потребовать нескольких операций чтения и записи, в зависимости от того, что вы делаете с дампом.

ALTER и dump + reload необходимо для того, чтобы таблица была заблокирована все время, или, по крайней мере, вы должны избегать записи в таблицу.

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

PTOSC делает

  1. Создайте новую таблицу, внесите изменения (INT в BIGINT).
  2. Добавить TRIGGER ловить любые пишет.
  3. пройтись по таблице, копируя куски строк.
  4. Когда почти закончено, происходит короткая пауза (блокировка) с информацией, захваченной триггером, меняет местами таблицы и очищает.

Я бы не ожидал никаких различий между MySQL и MariaDB для любого метода. Однако ptosc, вероятно, недоступен в Windows.

Что касается ресурсов, каждому нужно место для второй копии таблицы, а может и больше. Помните о влиянии innodb_file_per_table. Если таблица в настоящее время находится в собственном файле, и значение параметра равно «1», то обработка диска чистая. В противном случае ibdata1 или табличное пространство или что-то еще может значительно разрастутся и старое пространство не освободится.

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