Кратко — проверенные стратегии с минимальной блокировкой и риском потери данных, плюс примерный пошаговый план.
1) Если значение можно вычислять на‑лету — используйте вычисляемый/генерируемый столбец или представление
- MySQL: `ALTER TABLE payments ADD COLUMN new_amount DECIMAL GENERATED ALWAYS AS (amount * $1.0$) VIRTUAL;` (или STORED при необходимости индексации).
- PostgreSQL (версии с поддержкой GENERATED): аналогично.
Плюс: нулевой бэкап/бэкофлайн, нет массовых UPDATE.
2) Онлайн DDL-утилиты (рекомендовано для MySQL/InnoDB)
- pt‑online‑schema‑change или gh‑ost: создают shadow таблицу, копируют данные онлайн и переключают таблицы с минимальной паузой. Используются для добавления/изменения столбцов и индексов практически без блокировок.
Плюс: проверено в проде; минус — дополнительная сложность, тестирование.
3) Пошаговый безопасный бэкап- и backfill-подход (универсален)
Шаги:
a) Добавить новый nullable столбец без DEFAULT:
ALTER TABLE payments ADD COLUMN new_amount DECIMAL;
b) Подготовить механизм синхронизации новых/изменённых строк во время заполнения:
- триггер на запись/обновление, или двойная запись в приложении, либо считывание binlog/replication stream.
c) Бэкап/бэкофлайн и массовое заполнение пакетами (чтобы не держать одну долгую транзакцию):
Пример итеративного обновления:
- выбрать batch size = $10000$ - в цикле: UPDATE payments SET new_amount = amount * $1.0$ WHERE id BETWEEN start AND end;
— не обновлять всю таблицу одной транзакцией, делать коммиты каждые пакет.
d) После полного backfill — отключить триггеры/двойную запись, проверить целостность.
e) Сделать ALTER для NOT NULL/DEFAULT (если нужно) в короткой операции:
ALTER TABLE payments ALTER COLUMN new_amount SET NOT NULL; или добавить DEFAULT отдельно.
f) При необходимости — удалить старый столбец.
Замечания по batch-обновлению:
- Используйте индекс по id/датам для быстрого выбора пакетов.
- Контролируйте нагрузку (sleep между пакетами), мониторьте I/O и replication lag.
- Размер пакета примерный: $1000$-$10000$ в зависимости от нагрузки.
4) Shadow‑table + swap (если нельзя применять online DDL)
- Создать payments_new с нужной схемой.
- Копировать данные пакетами, при этом логировать изменения (триггеры/двойная запись).
- На короткой паузе (секунды) применить оставшиеся изменения и RENAME TABLE swap.
- Минус — сложнее, требует точной синхронизации.
5) Подходы по СУБД (коротко)
- MySQL/InnoDB: пробуйте ALGORITHM=INPLACE, используйте pt‑online‑schema‑change или gh‑ost. Добавление столбца без DEFAULT часто быстрый.
- PostgreSQL: версии >= 11/12 оптимизируют добавление столбца с DEFAULT; для старых версий требуется полная перезапись. Используйте CREATE INDEX CONCURRENTLY для индексов, ALTER TABLE ... SET NOT NULL делайте отдельно (после backfill).
6) Общие меры предосторожности
- Тестировать на копии БД.
- Бэкап/снимок перед изменением.
- Следить за транзакционными логами и репликацией.
- Ограничить длительность транзакций, избегать массовых операций в одной транзакции.
- Планировать в период низкой нагрузки и ставить мониторинг/алерты.
Пример рабочего плана (рекомендуемый, коротко)
- Добавить nullable столбец.
- Включить триггер/двойную запись.
- Backfill пакетами (batch = $10000$), мониторить.
- Отключить триггер, проверить.
- Сделать SET NOT NULL / добавить DEFAULT.
- Удалить старый столбец (если нужно).
Если дадите СУБД (MySQL/Postgres версии) и объём таблицы, могу предложить точные команды и пример скрипта для батчевого бэкапа.