Следовательно, нам нужно, чтобы скрипт выполнялся быстро, не влияя на обслуживание в клиентской части.
Это всего лишь мнение, но оно основано на опыте: это плохая идея.Лучше иметь короткие (заранее объявленные, если возможно) запланированные простои, чем рисковать.
Единственное исключение - если вам действительно все равно, повреждены ли данные в этих таблицах, и вы можете быть недоступны в течение длительного периода.
В этой ситуации, основанной на типах thизменений, которые вы вносите, и уже проведенного вами тестирования, похоже, что риск очень минимален, поскольку вы протестировали изменения и ДОЛЖНЫ быть в состоянии сделать это безопасно, но ничего не гарантировано.
Во-первых, вам нужно иметь запасной план на случай, если что-то пойдет не так.Краткая версия МИНИМАЛЬНОГО разумного плана будет включать:
- Завершение работы сайта
- Создание резервной копии базы данных
- Запуск сценария
- проверить целостность БД
- вернуть сайт в режим онлайн
Было бы очень неразумно пытаться сделать такое обновление, пока веб-сайт работает.вы рискуете потерять работу в течение продолжительного периода времени, если что-то пойдет не так.
В ХОРОШЕМ плане вы также можете проверить это по копии базы данных и копии веб-сайта (среда тестирования / промежуточной проверки)сначала, а затем выполните действия, описанные выше, для обновления живого сервера. Вы уже сделали это.Престижность!
Существуют даже лучшие методы для создания такого обновления, но компромисс между временем простоя и безопасностью в большинстве случаев не составляет никакого труда.