WooCommerce 後台越來越慢？新北網店先檢查「已排程動作」資料表

最後更新：2026/10/13

網店剛開的時候，後台點什麼都很快；開了一兩年，訂單列表要轉好幾秒，改一個商品要等半天，前台結帳偶爾還會逾時。很多新北的網店老闆第一個想到的是換主機。先別急，打開資料庫看一看，常常會發現兩張特別大的表：wp_actionscheduler_actions 和 wp_actionscheduler_logs。

這兩張表是 WooCommerce 的「已排程動作」。下面先說它在做什麼，再教你怎麼讓它不再無限長大，以及怎麼安全地清掉已經堆積的舊紀錄。

不想自己改？把這篇交給 AI

把這篇的網址（或全文）連同下面這段話貼給 AI：

我的網站是 WordPress，有裝 WooCommerce。我想照下面這篇文章，檢查並清理 WooCommerce 的「已排程動作」，讓後台不要越來越慢。
請先問我：我能不能進 phpMyAdmin、資料表的前綴是不是 wp_。
問清楚之後，再一步一步告訴我：要用哪一段程式碼、貼在哪裡、哪些地方要換成我自己的資料，以及改完怎麼測試。
如果文章的做法不適合我的網站，請直接告訴我原因和替代做法。
文章：（貼上這篇的網址，或整篇內容）

改之前先備份，密碼不要貼給 AI。

「已排程動作」在做什麼

WooCommerce 有很多事情會先排進一個待辦清單，稍後在背景處理：寄訂單通知信、更新報表數字、清理過期的購物車、跟其他服務同步資料；裝了訂閱制、電子報、物流這類外掛，排進來的工作更多。這個待辦清單就是「已排程動作」，到「WooCommerce → 狀態 → 已排程動作」可以看到每一筆。

每件工作做完，WooCommerce 會留下一筆紀錄，再加上幾筆執行過程的日誌。完成和取消的紀錄預設保留 30 天；失敗的紀錄，舊版本完全不會自動清掉，新版本則保留 3 個月。訂單多、外掛多的商店，每天排進來的工作就多，紀錄留得越久，表就越大，後台每次查詢都要翻過這些紀錄。

打開「已排程動作」時，順便看一下「失敗」和「待處理」的數量。待處理一直累積、時間早就過了卻沒有執行，通常代表網站的排程沒有正常運作，或某個外掛出了問題，這比表很大更需要先處理。

讓紀錄只留 7 天

一般的商店不需要把一個月前的「寄信成功」紀錄留著。加上這段程式碼，完成和取消的紀錄只留 7 天，失敗的留 30 天，方便出問題時回頭查：

// 排程動作的紀錄：完成、取消的只留 7 天（預設 30 天）
add_filter('action_scheduler_retention_period', function () {
    return 7 * DAY_IN_SECONDS;
});

// 失敗的紀錄留 30 天，方便回頭查問題（新版預設留 3 個月）
add_filter('action_scheduler_retention_period_for_failed', function () {
    return 30 * DAY_IN_SECONDS;
});

我們在測試站放了 20 筆 10 天前完成的紀錄、20 筆 40 天前失敗的紀錄。沒加程式碼時，清理程序跑完一筆都沒少；加了之後，兩種紀錄都被清掉。清理程序是 WooCommerce 自己定時跑的，加了程式碼不用另外做什麼，舊紀錄會一批一批被清掉。

程式碼放在 Code Snippets 這類外掛或子主題，放法和備份方式見〈WooCommerce 結帳頁改成台灣習慣〉。

已經堆了很多，一次清掉

如果表已經大到後台打不開，等清理程序慢慢清太久了，可以用主機的 phpMyAdmin 手動清一次。動手前一定要完整備份資料庫。 先用查詢看看現在有多少筆：

-- 先看每種狀態各有幾筆
SELECT status, COUNT(*) AS n
FROM wp_actionscheduler_actions
GROUP BY status;

確認數字之後，刪掉 7 天前已經完成、失敗或取消的紀錄，再刪掉找不到對應工作的日誌：

-- 刪掉 7 天前已完成、失敗、取消的紀錄（待處理的不動）
DELETE FROM wp_actionscheduler_actions
WHERE status IN ('complete', 'failed', 'canceled')
  AND scheduled_date_gmt < UTC_TIMESTAMP() - INTERVAL 7 DAY;

-- 刪掉已經沒有對應工作的日誌
DELETE l FROM wp_actionscheduler_logs l
LEFT JOIN wp_actionscheduler_actions a ON l.action_id = a.action_id
WHERE a.action_id IS NULL;

幾個要注意的地方。表名前面的 wp_ 是預設的資料表前綴，你的網站可能不一樣，在 phpMyAdmin 左邊的資料表清單看得到。待處理（pending）和執行中（in-progress）的紀錄千萬不要刪，那是還沒做完的工作，例如下個月要扣款的訂閱。網路上有些教學是把某個狀態的紀錄全部刪掉，不分日期；保留最近 7 天，出問題時還有紀錄可以查。

其他常讓商店變慢的原因

排程動作清乾淨之後，如果還是慢，接下來看這幾個地方。

外掛裝太多、沒有測試就上線，是最常見的原因。功能相近的外掛裝了好幾個、早就不用的外掛沒有刪，每一個都可能在每次載入頁面時多做一些事，主機的 CPU 被吃到接近滿載的情況並不少見。每個外掛先在測試環境試過，確定需要再裝上正式網站。

資料庫本身也可以優化。WordPress 的資料表索引是照一般網站設計的，商品和訂單一多就不夠用，「Index WP MySQL For Speed」這個免費外掛會幫常用的資料表加上更合適的索引，我們維護的 WooCommerce 網站也有使用。主機如果有提供 Redis 這類物件快取，開起來也能減少重複查詢資料庫的次數。

最後是前台的速度：圖片壓縮、快取外掛、只載入需要的功能。這部分跟一般網站一樣，上線前的檢查可以看〈WordPress 網站上線前的檢查清單〉。