Полагаю универсального решения здесь нет. Все зависит от того, сколько "сервисов" пользуются вашей базой, насколько допустим простой каждого из них и насколько гибок Ваш код.
Можно представить себе, что миграция это изменение представления данных. Таким образом, у нас открывается потенциальная возможность использовать view, и работа из кода не напрямую с данными, а с этими самыми view. Т.о. Вы можете создавать новые временные столбцы, нацеливать на них view, а заполнять их при помощи триггера к примеру.
В mysql 5.6 (не прошло и 10 лет !, или прошло ?), в случае если Вы просто меняете имя столбца, копирование во временную таблицу, с соответствующим локом, не происходит.
Т.о. если вы обернете в единую транзакцию (с локом) переименование столбца, и нацеливание view обратно на "изначальное" имя, столбца, вероятно Вам удастся добиться минимального даунтайма.
Миграция, т.о. становится многоходовочкой, но Вы избавляете себя от страха за потерю данных после кривой миграции и упрощаете себе переключение между старыми \ новыми данными, т.к. вы управляете этим из кода миграций.
view имеет множество ограничений в случае "сложных" запросов, джойнов, у Вас должны быть соответсвующие индексы, чтобы view отрабатывало по ним и т д.
Думаю Вам стоит прикинуть всю сложность операционных работ по реализации данного решения, и решения описанного
Fortop чуть выше. И понять, чем Вы можете поступится, и что в Вашей системе проще реализуется сейчас, и через 1 год.
Средний
Простой
