FIXA ENORMA SQL-tabeller: wp_actionscheduler_actions & wp_actionscheduler_logs [WooCommerce tips]

WooCommerce det har blivit en mycket använd modul nättidning. SEO, produkt- och lagerhantering, ren och intuitiv kod, enkelt administrationsgränssnitt och de tusentals plugins som utvecklats för Woo, är bara några av anledningarna till att det förtjänar en chans när du tänker på att utveckla en onlinebutik.

Som alla CMS är Woo inget undantag från de konstigheter som kan uppstå i olika användnings- eller interaktionsscenarier med andra plugins. WordPress.
På en resursserver hårdvara ganska generös, jag märkte det databastjänst (mysqld) börjar kräva nästan 80-90% av RAM-minnet. Ett ganska allvarligt problem, för jag förstod inte var fel 110 kommer regelbundet (110: Tidsgräns för anslutning).
Vid närmare granskning av SQL-processer fann jag att en databas har två tabeller med ganska stora volymer: wp_actionscheduler_actions si wp_actionscheduler_logs.

normalt schemalagda åtgärder av WooCommerce Åtgärdsplanerare de bör raderas automatiskt efter att de har körts. Detta händer inte alltid, och de fastnar i wp_actionsscheduler_actions med status: misslyckades, avbokad, väntan eller fullborda.

I bilden ovan visas tabellerna "wp_actionsscheduler"De har bara drygt 15 MB. Jag är ledsen att jag inte blev inspirerad att ta en skärmdump när de gjorde det 1.2 GB. Trots det är 15 MB ganska mycket för en tabell som innehåller de programmerade åtgärderna för WooCommerce.
Dessa "svullna" tabeller är resultatet av det WP-Cron raderar inte poster som har status "misslyckades","avbokad"Och"fullborda“. Normalt bör dessa poster raderas automatiskt från databasen.
De schemalagda åtgärderna och deras tillstånd kan ses mycket enkelt och in WooCommerce →  status →  Schemalagda åtgärder.

Hur man rengör rännorna "misslyckades","avbokad"Och"fullborda"I wp_actionscheduler_actions si wp_actionscheduler_logs

Vi kommer åt databasen genom phpMyAdmin, sedan i SQL kör vi kommandoraderna i tur och ordning:

DELETE FROM `wp_actionscheduler_actions` WHERE `status` = 'canceled'

DELETE FROM `wp_actionscheduler_actions` WHERE `status` = 'complete'

DELETE FROM `wp_actionscheduler_actions` WHERE `status` = 'failed'

När denna tabell har rengjorts betyder det inte att problemet är löst. Som jag sa ovan är huvudorsaken inaktiveringen av WP-Cron-tjänsten av olika skäl. Således kan poster med "zombie" -status inte längre raderas.
Det är väldigt viktigt att veta att om du har en webbutik på WooCommerce, och den är ansluten till Facebook Shops via plugin "Facebook för WooCommerce", synkroniserar den automatiskt produkterna från WooCommerce med ditt Facebook Shops-konto. Och han gör det var 15:e minut. Om dessa SQL-poster inte kontrolleras kan du få flera hundratusentals rader"wc_facebook_regenerate_feed" i "wp_actionscheduler_actions".

Detta intervall är ok för butiker som har ett stort antal beställningar och lager av Facebook Shops-produkter måste uppdateras ständigt. Om du fortfarande tror att dessa synkroniseringar mellan Facebook och din butik kan göras en gång var 24: e timme kan kodraden nedan hjälpa till.

Öppna filen functions.php för temat WordPress / WooCommerce som din butik kör på och lägg till:

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

Nedan kan vi ställa in ett intervall på en vecka för automatisk rengöring:

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

När du har sparat dessa ändringar har du inga problem med gigantiska tabeller för "wp_actionscheduler_actions".