Виправити величезні таблиці SQL: WP_Actionscheduler_actions & wp_actionscheduler_logs [Поради WooCommerce]

ВООКУМЕРСЬКА він став дуже використовуваним модулем все більше і більше журнал онлайн. SEO, керування продуктами та запасами, чистий та інтуїтивно зрозумілий код, простий інтерфейс адміністрування та тисячі плагінів, розроблених для Woo, – це лише деякі з причин, чому він заслуговує шансу, коли ви думаєте про створення онлайн-магазину.

Як і будь-яка CMS, Woo не позбавлена ​​дивацтв, які можуть з’явитися в різних сценаріях використання або взаємодії з іншими плагінами WordPress.
На сервері з ресурсами обладнання досить щедро, я це помітив служба баз даних (mysqld) починає запитувати майже 80– 90% оперативної пам'яті. Досить серйозна проблема, тому що я просто не зрозумів звідки періодично виникає помилка 110 (110: Час очікування підключення минув.).
La o verificare mai atenta a proceselor SQL, am descoperit ca o baza de date are doua tabele cu volume destul de considerabile: wp_actionscheduler_actions і wp_actionscheduler_logs.

In mod normal actiunile programate але WooCommerce Action Scheduler ar trebui sa se stearga automat dupa ce sunt executate. Nu se intampla mereu acest lucru, iar ele raman blocate in wp_actionsscheduler_actions cu statusul: failed, canceled, pending або complete.

In imaginea de mai sus, tabelele “wp_actionsscheduler” nu au decat putin peste 15 MB. Imi pare rau ca nu am fost inspirat sa fac un screenshot cand aveau1.2 GB. Chiar si asa, 15 MB este destul mult pentru un tabel care contine actiunile programate ale WooCommerce.
Aceste tabele “umflate” rezulta din cauza ca WP-Cron nu sterge intrarile care au status “failed“, “canceled” і “complete“. Зазвичай ці записи мають бути автоматично видалені з бази даних.
Запрограмовані дії та їхній статус можна легко побачити в ВООКУМЕРСЬКА →Статус →Заплановані дії.

Як ми чистимо стоки? “failed“, “canceled” і “complete” Зwp_actionscheduler_actions і wp_actionscheduler_logs

Ми отримуємо доступ до бази даних через phpMyAdmin, потім в SQL по черзі виконуємо командні рядки:

ВИДАЛИТИ З `wp_actionscheduler_actions` WHERE `status` = 'canceled'

ВИДАЛИТИ З `wp_actionscheduler_actions` WHERE `status` = 'complete'

ВИДАЛИТИ З `wp_actionscheduler_actions` WHERE `status` = 'failed'

Якщо цю таблицю очищено, це не означає, що проблему вирішено. Як я вже сказав вище, основною причиною є деактивація служби WP-Cron з різних причин. Таким чином, записи зі статусами “зомбі” їх більше не можна видалити.
Este foarte important de stiut ca daca aveti un magazin online pe WooCommerce, iar acesta este conectat la Facebook Shops prin plugin-ul “Facebook for WooCommerce“, acesta sincronizeaza automat produsele din WooCommerce cu contul dvs. de Facebook Shops. Si o face cam la 15 minute. Aceste intrari in SQL daca nu sunt controlate, puteti obtine cateva sute de mii de linii “wc_facebook_regenerate_feed” у “wp_actionscheduler_actions“.

Acest interval este ok pentru magazinele care au un numar mare de comenzi si este nevoie ca stocul produselor din Facebook Shops sa fie actualizat constant. Daca totusi considerati ca aceste sincronizari dinre Facebook si magazinul dvs. se pot face odata la 24 de ore, linia de cod de mai jos va poate ajuta.

Deschideti fisierul functions.php al temei de WordPress / WooCommerce pe care ruleaza magazinul dvs. si adaugati:

add_filter( 'wc_facebook_feed_generation_interval', function(){ return HOUR_IN_SECONDS * 24; } );

In continuare putem seta un interval de o saptamana pentru curatare automata:

add_filter( 'action_scheduler_retention_period', 'wpb_action_scheduler_purge' );
function wpb_action_scheduler_purge() {
 return WEEK_IN_SECONDS;
}

Odata salvate aceste modificari nu veti mai avea probleme cu tabele gigant pentru “wp_actionscheduler_actions”.