Таблица WP_Options бесконечно увеличивается в размере.

У меня есть проблема с моей страницей на wordpress (магазин woocommerce, родительская тема woodmart), где таблица wp_options в моей базе данных увеличивается почти на 50 МБ по размеру, как я думал, примерно каждые 10 минут, но оказывается, интервал совершенно случайный, вчера в течение дня это было примерно 10 минут, но вечером — каждый час или около того.

Несколько дней назад, когда я это заметил, она достигла рекорда в 140 ГБ, и продолжала бы расти. Оптимизация таблицы решает проблему на некоторое время и снижает ее до 300 МБ, но она медленно снова увеличивается после случайного промежутка времени.

Эта проблема сохраняется на 2 веб-сайтах, которые у меня есть. 1. работающий магазин woocommerce (это был тот с базой данных 140 ГБ, до оптимизации) и 2. новая версия того же магазина в разработке (у него размер таблицы составлял 25 ГБ, когда я его обнаружил.)

Итак, следующие данные касаются моей страницы разработки:

Я оптимизировал 25 ГБ базу данных, снизил ее до около 200 МБ, и за 6 часов она достигла 1,3 ГБ.

Я проверил журнал активности WP и ничего не нашел, когда она увеличивалась на 50-100 МБ случайно.

Я также проверил WP cron, и, похоже, проблема не в заданиях cron. Она увеличивалась, когда никаких заданий cron не работало, и после выполнения нескольких, которые, как я думал, могут быть ответственны, никаких изменений не произошла.

В SQL, если я выполню:

SELECT COUNT(*) AS row_count, SUM(LENGTH(option_value)) AS total_data_size, AVG(LENGTH(option_value)) AS avg_row_size FROM wp_options;

возвращает:
row_count: 15749
total_data_size: 5610091
avg_row_size: 356.2189

Так что согласно этому, мой средний размер строки составляет 300 байт, а общий размер wp_options должен быть 5.6 МБ.

Но если я выполню SHOW TABLE STATUS, я получаю такой результат:

Атрибут Значение Анализ
Строки 15,565 Соответствует приблизительному количеству строк, упомянутому ранее.

Avg_row_length 74,677 байт Каждая строка в среднем составляет ~74.6 КБ..

Data_length 1,162,362,880 Это общая величина данных (~1.16 ГБ).

Index_length 3,129,344 Размер индексов минимален (~3 МБ), поэтому индексы не являются значительным источником утечек памяти.

Data_free 6,291,456 Неиспользуемое пространство составляет только ~6 МБ, что означает, что фрагментация минимальна и не является основной причиной размера таблицы.

Row_format Динамический

Таким образом, хотя каждая строка содержит в среднем только 300 байт данных, каждая строка в среднем занимает 75 КБ!

Так что это должно быть простое решение, не так ли? Давайте просто найдем самую большую строку и….

SELECT option_name, LENGTH(option_value) AS option_value_length
FROM wp_options
ORDER BY option_value_length DESC;

Это показывает мне, что самая большая запись option_value_length равна 481491,
но 25-я уже 37280.

Проверяя опции autoload:

SELECT option_name, LENGTH(option_value) AS option_size, autoload FROM wp_options WHERE autoload = ‘yes’ ORDER BY option_size DESC LIMIT 50;

Показывает мне самый большой option_size равный 33749, 6-й уже уменьшился до 7572.

Маловероятно, что проблема заключается в транзитах, потому что при оптимизации моей базы данных она снижалась до около 100 МБ, не удаляя никаких транзитов.

На этом этапе я довольно сильно застрял, собираюсь попробовать отключить дочернюю тему и использовать родительскую, и посмотреть, сохраняется ли проблема… Хотя моя дочерняя тема не должна ничего записывать в wp_options…. У кого-нибудь есть хорошие идеи?