Удаление значений из таблиц "cl"

Главный вопрос:

Их можно удалить, если у вас есть другие средства для обновления продуктов, которые еще не обработаны, т.Е. При условии, что вы собираетесь вручную ("обновить при сохранении") или программно обновить их.

Если вы удаляете идентификаторы ниже версии в таблице view_state, то вы в основном удаляете записи из обработки при следующем запуске cron (и, в частности, при выполнении задания indexer_update_all_views, которое выполняется каждую минуту), это не влияет все, что касается индексов "обновить при сохранении", поскольку эти данные больше не используются.

Когда вы переключаете индексатор на "обновление при сохранении", триггеры MySQL фактически удаляются для этого индексатора/представления, поэтому вы должны видеть, что в вашем случае обновления запасов больше не запускают вставки данных в таблицу cataloginventory_stock_cl и mode для cataloginventory_stock в mview_state должно быть disabled.

Бонусный вопрос

Как сказал Алессандро в комментарии к другому ответу, если вы используете "обновить при сохранении" существует нулевой риск. Если вы планируете продолжать использовать "обновление по расписанию", также существует нулевой риск, если вы НЕ измените идентификатор автоматического увеличения таблицы(таблиц) *_cl*.

*Если бы вы это сделали, вам также нужно было бы сбросить version_id в таблице mview_state

Жизненно важной частью таблиц *_cl является автоматическое увеличение, после обработки строки фактические данные столбца, честно говоря, не имеют значения, до этого entity_id, очевидно, является ключевым для обновления индекс соответствующих сущностей.

Magento придерживается того же мнения (плюс, чтобы размер таблицы был небольшим/управляемым), и причина, по которой я говорю, что риск равен нулю, заключается в том, что в полночь каждый день выполняется задание cron indexer_clean_all_changelogs и фактически очищает все обработанные строки журнала изменений из таблиц *_cl - это в конечном итоге вызывает Magento\Framework\Mview\View\Changelog::clear(), где передается последний version_id и удаляются все строки, равные или меньшие идентификатору в *_cl.

Поэтому, если бы вы очистили их программно, я бы рекомендовал подключиться к этому метод (через его интерфейс).

Резюме

В конце дня, даже если вам удастся что-то испортить (если вы не повредите структуру таблицы), вы можете просто настроить все индексы для запуска при сохранении, сбросить их все, обновить их все, а затем вернуть их в расписание, чтобы убедиться, что все данные полностью обновлены - это удобная цепочка команд, помогающая автоматизировать это:

bin/magento indexer:set-mode realtime && bin/magento indexer:reset && bin/magento indexer:reindex && bin/magento indexer:set-mode schedule

Или если есть проблемы с тем, что version_id не синхронизировано между mview_state и *_cl затем вам многим нужно вручную выровнять их (т.Е. Убедиться, что version_id в view_state находится на уровне/ниже следующего идентификатора автоматического увеличения в таблице *_cl - очевидно, что это далеко от идеала и не рекомендуется, это чисто на этапе аварийного восстановления!