Ничто из этого не должно блокировать таблицы, которые вы фактически используете. В настоящее время вы пишете только в таблицу logging
и только в новые записи.
Вы выбираете из таблицы logging
только СТАРЫЕ записи и записываете в таблицу, в которую вы не пишете, за исключением процесса архивирования.
Шаги, которые вы делаете, звучат нормально. Я бы пошел на шаг дальше, и вместо удаления по дате просто введите INNER JOIN
в свою архивную таблицу в поле id
- тогда вы удалите только те записи, которые вы заархивировали.
Как примечание: 600 тыс. Записей совсем не велики. У нас есть производственные БД с таблицами более 2 миллиардов строк, и я знаю, что у некоторых других здесь есть базы данных с миллионами вставок в минуту в транзакционные таблицы.
Изменить:
Я забыл включить изначально, еще одно преимущество вашего запланированного метода заключается в том, что каждый шаг изолирован. Если по какой-либо причине вам необходимо остановиться, ни один из ваших шагов не является разрушительным или зависит от следующего шага, выполняемого немедленно. Вы можете заархивировать много записей, а затем выполнить удаление на следующий день или в одночасье, не создавая проблем.