N8N 工作流效能優化：讓執行速度快 3 倍的 5 個調整技巧

工作流剛建好的時候跑得飛快，資料一多就開始卡，一次執行要等好幾十秒甚至 timeout？這不是 n8n 慢，多半是工作流設計沒考慮到資料量成長。

這篇整理 5 個實測有效的調整技巧。每一個都附上「為什麼會慢」的原因，以及具體怎麼改。照著做，多數工作流的執行時間可以砍掉一半以上，重的甚至快 3 倍。

先搞清楚：你的工作流到底慢在哪

優化前先量測，不要憑感覺。打開任一筆執行紀錄（Executions），每個節點右上角都會顯示該節點花了多久。

通常瓶頸落在這幾類節點：

HTTP Request / API 節點：等待外部服務回應，這是最常見的瓶頸。
資料庫查詢節點：一次撈太多 row，或查詢沒走索引。
Code 節點：迴圈裡塞了重運算，或在迴圈內呼叫 API。
迴圈節點（Loop / Split In Batches）：一筆一筆序列處理，數量一多就爆。

找到花最久的那 1～2 個節點，集中火力改它，比到處微調有效得多。

技巧 1：減少在節點之間流動的資料量

n8n 的每個節點都會把上一個節點的完整輸出接過來。如果你在第一個節點撈了 5,000 筆、每筆 30 個欄位的資料，這整包會一路被複製、序列化、傳遞到後面每一個節點——即使你只用得到其中 2 個欄位。

改法：盡早瘦身。

在資料源頭就過濾與裁切：

API / 資料庫查詢時就帶上 limit、select 指定欄位、where 條件，不要全撈回來再用 n8n 過濾。
撈回來後第一個動作放 Edit Fields (Set) 節點，只保留後續真正會用到的欄位，把肥大的 raw payload 丟掉。
用 Filter 節點提早把不需要處理的 item 擋掉，別讓它們白白流過十個節點。

資料量是效能的乘數。前面少一半的資料，後面每個節點都跟著快一半。

技巧 2：用批次處理取代逐筆迴圈

很多人習慣用 Loop Over Items（Split In Batches） 一筆一筆處理，每一輪都呼叫一次 API。100 筆資料就是 100 次序列往返，每次 200ms，光等待就 20 秒。

改法分兩種情況：

情況 A — API 支援批次： 很多 API 接受一次傳一個陣列（bulk insert、batch update）。把資料整理成一個陣列，一次 HTTP Request 送出，100 次往返變 1 次。

情況 B — API 只能逐筆： 那就讓它們平行跑，而不是序列等待。n8n 的 HTTP Request 節點在處理多個 item 時本來就有一定並行度；重點是不要用 Loop Over Items 把它強制拆成一輪一輪。直接讓多個 item 進 HTTP Request 節點，n8n 會自己併發，比手動迴圈快得多。

只有當你需要「上一輪結果決定下一輪」的依賴關係時，才真的需要序列迴圈。其他情況，迴圈通常是效能殺手。

技巧 3：關掉不需要的執行資料儲存

n8n 預設會把每一筆執行的完整輸入輸出資料都存進資料庫。資料量大或執行頻繁時，光是寫入這些紀錄就拖慢速度，還會把資料庫撐爆。

到工作流的 Settings 裡調整這幾項：

Save successful executions：穩定運行的高頻工作流，可以關掉成功紀錄的儲存，只留失敗的（設成 Save failed executions only）。出錯時還查得到，平常不浪費寫入。
Save manual executions：手動測試的紀錄通常不需要留。
Save execution progress：這個選項會在每個節點執行後都寫一次資料庫，方便中斷後續跑，但對長工作流是明顯的效能負擔。確定不需要中途續跑就關掉。

另外記得設定執行紀錄自動清理（環境變數 EXECUTIONS_DATA_PRUNE=true 搭配 EXECUTIONS_DATA_MAX_AGE），別讓舊紀錄無限堆積——這部分可以一起參考 n8n 備份與更新 SOP。

技巧 4：把重邏輯拆成子工作流

單一工作流塞太多節點，不只難維護，n8n 在記憶體裡要扛的狀態也越大。尤其 Code 節點裡的大型運算、或者會被多個地方重複用到的邏輯，留在主流程裡會反覆拖慢整體。

改法：用 Execute Sub-workflow 節點拆出去。

把獨立、可重用的邏輯（例如「格式化發票資料」「呼叫某個 API 並重試」）抽成子工作流。
主流程只在需要時呼叫，記憶體佔用更可控，每段也能單獨測試與優化。
子工作流可以設定只回傳必要欄位，避免把一大包中間資料倒回主流程。

拆分的細節與設計原則，可以看 n8n 子工作流模組化設計。

技巧 5：高併發場景啟用 Queue Mode

如果你是自架 n8n，且工作流觸發頻繁（webhook 一秒好幾發、或多個排程同時觸發），預設的單一主程序會變成瓶頸——所有執行擠在同一個 process 裡排隊。

改法：切換到 Queue Mode。

Queue Mode 用 Redis 當佇列，把工作流執行分派給多個獨立的 worker 程序處理。好處是：

主程序只負責接收觸發與分派，不被執行卡住。
可以水平擴充 worker 數量，併發能力跟著 worker 數線性成長。
單一工作流出問題不會拖垮整台。

設定方式是把 EXECUTIONS_MODE=queue，接上 Redis，再啟動數個 n8n worker 程序。這是給有規模需求的場景；小流量自架或 n8n Cloud 不需要動這塊。

優化後一定要驗證

改完別急著收工，跑一筆真實資料量的執行，對照優化前的節點耗時，確認：

瓶頸節點的時間真的降下來了。
輸出結果跟優化前一致（特別是改了批次處理、平行化之後，確認資料沒漏沒重複）。
失敗紀錄還留著，出問題查得到。

效能優化最常見的坑，是為了快而改壞了正確性。每改一項就驗一次，比一次改五項再來抓哪裡出錯省事得多。

小結

n8n 效能優化的核心就一句話：讓更少的資料、用更平行的方式、被更精簡的流程處理。

五個技巧的優先順序，建議從「減少資料量」和「批次/平行化」開始——這兩個對多數工作流的提升最直接，也不需要動到基礎設施。確定不夠快、而且是高併發場景，再考慮 Queue Mode。

如果你的工作流不只是慢、而是會時不時噴錯，那要先處理穩定性——可以接著看 N8N 執行失敗自動重試：設計穩健工作流的錯誤補償機制和 n8n 常見錯誤 Top 10。