你的数据库是不是又快“爆”了？
作为一名在低代码自动化领域摸爬滚打多年的老兵，笔者见过太多这样的场景：业务跑得飞起，日志、临时表、缓存数据疯狂堆积。起初大家不以为意，直到某天系统突然卡顿，或者磁盘告警，才手忙脚乱地去手动清理。
“手动”这两个字，在技术圈里其实就是“不稳定”和“低效率”的代名词。特别是对于使用 n8n 这种 7x24 小时运行的自动化工具来说，与其每次都要人肉介入，不如让 n8n 自己学会“断舍离”。
今天，N8N大学 就带大家实战一把，利用 n8n 的 Schedule（定时任务） 节点，配合数据库操作，搭建一套自动清理旧数据的机制。这不仅是为了省空间，更是为了让你的自动化流程始终保持轻盈高效。
准备工作：你需要这些“弹药”
在开始之前，我们需要把基础环境搭建好。这就像做饭前得先备好菜一样，简单但不可或缺。
1. 一个能运行的 n8n 环境：无论是 Docker 部署、云服务器还是本地安装，只要 n8n 能跑就行。
2. 目标数据库的连接信息：这里我们以 PostgreSQL 为例（MySQL 逻辑完全一致）。你需要准备好 Host、端口、数据库名、用户名和密码。
3. 一个清醒的大脑：数据无价，生产环境操作务必谨慎。建议先在测试环境跑通。
核心实操：搭建自动清理管道
我们将创建一个独立的 Workflow，它只做一件事：定时唤醒，连接数据库，执行删除，然后睡觉。
步骤一：设置“闹钟”——Schedule 节点
这是整个流程的触发源。点击 "+" 号，搜索并添加 Schedule 节点。
在参数设置中，我们选择 Custom（自定义）模式，这样灵活性最高。假设我们想每天凌晨 3 点执行一次清理任务：
- Rule Interval: 选择 Cron。
- Cron Expression: 输入
0 3 * * *（代表每天的第3小时第0分钟）。
笔者注：如果你是新手，可以点击右侧的“生成表达式”按钮，通过图形化界面选择时间，避免语法错误。
步骤二：连接数据库——Postgres 节点
从 Schedule 节点的输出端口拉出一条连线，搜索并添加 Postgres 节点（如果是 MySQL 则选择 MySQL 节点，操作逻辑完全相同）。
在 Parameters 中填写你的数据库连接信息。为了安全，强烈建议将这些敏感信息保存在 n8n 的 Credentials（凭证） 中，而不是直接写在节点里。
连接成功后，我们需要执行 SQL 语句。在 Node 选项中：
- Operation: 选择 Execute Query（执行查询）。
- Query: 这里是核心，写入删除语句。
步骤三：编写清洗逻辑——SQL 语句
在 Postgres 节点的 Query 字段中，我们需要写一条 DELETE 语句。为了防止误删，建议先用 SELECT 验证，确认无误后再改为 DELETE。
一个典型的清理“30天前日志”的 SQL 示例：
DELETE FROM logs WHERE created_at < NOW() - INTERVAL '30 days';
如果你希望每次只清理一部分（防止一次性删除导致锁表），可以加上 LIMIT：
DELETE FROM logs WHERE created_at < NOW() - INTERVAL '30 days' LIMIT 1000;
这条语句的意思是：删除 logs 表中，创建时间早于当前时间30天的记录，且每次最多删1000条。
步骤四：添加“安全门”——IF 节点（可选但推荐）
虽然 Schedule 已经很定时了，但我们有时希望增加一层逻辑判断。比如：只有当数据库连接成功时才执行删除。
你可以在 Postgres 节点后面接一个 IF 节点：
- 条件设置为：Postgres 节点的
json.status等于success。 - True 分支连接后续的删除操作（如果你把删除分成了两个步骤的话）。
不过对于大多数场景，直接在 Postgres 节点执行删除即可。最后，记得保存 Workflow 并将其切换为 Active（激活状态）。
避坑指南：实战中的“血泪”经验
看似简单的流程，新手操作时往往会踩几个坑。N8N大学 提醒你注意以下两点：
1. 时区问题：为什么任务没在凌晨3点跑？
n8n 默认使用的是 UTC 时间。如果你的服务器位于北京时间（UTC+8），你设置的 0 3 * * * 实际上是 UTC 时间的凌晨3点，也就是北京时间上午11点。
解决方案：在 Schedule 节点的 Cron 表达式中，将时间偏移。或者，更推荐在 Docker 部署 n8n 时，直接配置环境变量 TZ=Asia/Shanghai，让 n8n 识别本地时区。
2. 大表删除导致的“锁表”危机
如果你的表数据量达到百万级，直接执行 DELETE ... WHERE ... 可能会锁死整张表，导致业务查询卡顿甚至超时。
解决方案：采用“分批删除”策略。不要试图一次性删干净。在 SQL 语句中使用 LIMIT（如上文示例），并利用 n8n 的 Split Out 或循环机制，或者设置一个较短的 Cron 频率（如每小时一次），每次只清理一小部分。这才是生产环境的正确姿势。
FAQ 问答
Q1: 除了数据库，这个方法能用来清理文件服务器上的旧文件吗？
完全可以。思路是一样的：Schedule 节点触发 -> 执行 Shell 命令（使用 SSH 节点连接服务器）-> 使用 find /path -mtime +30 -delete 这样的命令来删除文件。逻辑是通用的。
Q2: 如果删除过程中报错了，n8n 会通知我吗？
默认情况下，n8n 只会在 Workflow 执行记录里显示红色错误。如果你想收到通知，可以在 Postgres 节点后连接一个 IF 节点，判断执行状态，如果失败，则调用 Telegram、Slack 或 Email 节点发送警报。
Q3: Schedule 节点支持“工作日”执行吗？
支持的。使用 Cron 表达式即可。例如，只在周一到周五执行：0 8 * * 1-5。最后一个数字代表星期几（0-6，0是周日，1-6是周一到周六）。
总结与资源
自动化清理旧数据是维护系统健康的重要一环。通过 n8n 的 Schedule 节点，我们可以将这一枯燥且必须的任务完全自动化，不仅解放了人力，也降低了因人为疏忽导致数据膨胀的风险。
记住，好的自动化不是一蹴而就的。建议先在测试库上运行几次，确认 SQL 语句无误后，再挂载到生产环境。
如果你在配置过程中遇到具体的报错，欢迎前往 N8N大学 (n8ndx.com) 查阅更多实战教程，或者在社区留言，笔者会为你解答。
