别让你的 MySQL 数据库“撑爆” n8n 的内存

笔者在 N8N大学 社区里，每天都能看到类似这样的求助：“为什么我用 n8n 读取 MySQL 数据，跑着跑着就报错了？”或者“数据量只有几万条，为什么 n8n 直接卡死了？”

如果你也遇到过这种情况，那大概率是因为你没有处理好 MySQL 节点的分页逻辑。

很多刚接触自动化的同学（包括当年的笔者）都有一个误区：觉得数据量不大，直接全量拉取省事。但 n8n 作为一个基于内存执行的工具，一次性把成千上万条数据塞进内存，不仅消耗巨大，还极易导致 Node.js 进程崩溃。今天，这篇硬核教程就带你彻底搞定 n8n MySQL 节点的分页处理，让你的自动化流程稳如老狗。

一、为什么必须做分页？

在开始实操前，我们先用大白话聊聊原理。

想象一下，你要把图书馆里所有的书都搬到桌子上。如果你一次只搬 10 本（分页），搬完后再去拿下一摞，虽然跑的趟数多，但桌子不会塌。但如果你试图一次性把所有书都抱在怀里（全量查询），结果必然是书撒一地，人也被压垮。

在 n8n 中，MySQL 节点执行查询后，会把结果以 JSON 数组的形式传递给下一个节点。如果数据量过大：

1. 内存溢出 (Out of Memory)：n8n 的前端界面会直接卡死或无响应。
2. 执行超时：n8n 有默认的执行超时限制，大查询通常会超时失败。
3. 数据库压力：长时间的锁表操作会影响业务数据库的性能。

所以，无论你用的是社区版还是企业版，对于超过 1000 条的数据查询，分页都是必选项。

二、核心实操：两种分页策略

在 n8n 中实现分页，主要有两种方式：一种是利用 MySQL 节点自身的参数（最简单），另一种是利用 Loop 节点 + SQL 语句（最灵活）。

方法一：利用 MySQL 节点的 Limit 参数（适合简单场景）

如果你只是想把数据分批处理，且不需要处理复杂的“断点续传”，n8n 的 MySQL 节点内置了一个超级实用的功能。

1. 添加 MySQL 节点：配置好你的数据库连接。
2. 选择模式：点击“Execute a SQL query”（执行 SQL 查询）。
3. 编写 SQL：输入你的查询语句，例如 SELECT * FROM your_table。
4. 设置分页参数：在节点配置的下方，找到 “Limit” 和 “Offset” 选项。
   
   • Limit：每次取多少条数据（例如 1000）。
   
   • Offset：从第几条开始取（初始为 0）。

注意：这种方法通常需要配合 Loop Over Items 节点或者 IF/Wait 节点来模拟循环，但在 n8n 的某些版本中，直接设置 Limit 只会取一次数据。如果想自动循环读取，方法二才是王道。

方法二：Loop + SQL 变量（企业级标准做法）

这是 N8N大学 推荐的通用方案，适用于任何数据量。我们需要利用 n8n 的 Set 节点和 Loop Over Items 节点来动态生成 SQL。

第一步：设置初始变量

添加一个 Set 节点（或者 Start 节点），定义两个变量：

• offset：值为 0
• limit：值为 1000（根据你的机器性能调整，建议 500-1000）

第二步：配置 Loop Over Items

添加 Loop Over Items 节点，连接上一步的 Set 节点。这里我们不需要真正的循环数组，而是为了利用它的“迭代”功能。

在 Loop 节点的配置中：

• Batch Size：设置为 1（每次循环处理一页）。
• Max Iterations：设置一个安全上限（例如 1000 次），防止死循环。

第三步：动态构建 SQL

在 Loop 节点之后，添加第二个 Set 节点（我们叫它“SQL构造器”）。这里用到了 n8n 的表达式功能：

• 新建字段 sql_query，值设为：
  SELECT * FROM users ORDER BY id ASC LIMIT {{ $limit }} OFFSET {{ $json.offset }}

这里的关键是利用了 Loop 节点每次输出的 offset 变量（Loop 节点会自动处理索引）。

第四步：执行查询与更新 Offset

1. 连接 MySQL 节点：
   • 使用 “From JSON” 模式，或者直接在 Query 中引用表达式：{{ $json.sql_query }}。
   • 关键点：在 MySQL 节点的“Options”中，取消勾选“Return All”，因为我们已经在 SQL 里控制了数量。
2. 连接 Set 节点（更新偏移量）：
   • 这个节点用来更新 offset，为下一次循环做准备。
   • 设置 offset 的值为：{{ $json.offset + $json.limit }}
   • 为了保持其他数据不变，记得把上一步的数据也透传过来。

第五步：结束循环的判断

如果你不知道数据总量，需要检测返回结果是否为空。在 MySQL 节点后加一个 IF 节点：

• 判断条件：{{ $json.data.length }} === 0
• 如果为空，则断开 Loop 的连接（或者结束 Workflow）。

三、避坑指南：实战中的血泪经验

在 N8N大学 的实测中，分页处理有 2 个极易踩坑的地方：

1. 数据一致性问题（脏读）

场景：你在分页读取数据的过程中，有新的数据写入了数据库，或者有数据被删除了。

后果：导致某条数据被读取两次，或者漏读。

解决方案：在 SQL 语句中必须加上 ORDER BY。通常按主键（如 ID）升序排列：ORDER BY id ASC。这样能保证分页的稳定性。

2. Offset 过大导致的性能退化

场景：如果你的数据量达到百万级，使用 OFFSET 1000000 时，MySQL 依然需要扫描前 100 万条数据，虽然不返回，但依然消耗性能，速度会越来越慢。

解决方案：
• 游标分页（Cursor-based Pagination）：不使用 Offset，而是记录上一页的最后一条 ID。
• SQL 变为：SELECT * FROM users WHERE id > {{ last_id }} ORDER BY id ASC LIMIT 1000。
• 这需要在流程中动态记录 last_id，逻辑稍复杂，但性能极佳。

四、FAQ 常见问题解答

Q1: n8n 社区版和企业版在分页上有区别吗？
A: 核心逻辑没有区别。企业版提供了更强大的“数据去重”和“错误重试”机制，但在分页查询的底层实现上，两者都依赖上述的 SQL 逻辑。

Q2: 为什么我的 Offset 在循环中不增加？
A: 检查你的 Set 节点配置。确保你是在 Loop 节点的输出数据基础上进行“Update Offset”操作，而不是新建了一个独立的流程。n8n 的数据流是线性的，必须把上一次的 offset 传递下去。

Q3: 有没有更简单的插件？
A: n8n 社区有一些自定义节点（Community Nodes）专门处理分页，但笔者建议新手先掌握上述的原生节点逻辑。原生方案最稳定，且不受第三方插件维护状态的影响。

总结与资源

处理 n8n MySQL 节点的分页，本质上是将“一次性大任务”拆解为“多次小任务”的过程。通过 Set 节点控制变量，配合 Loop 节点实现迭代，你可以轻松处理千万级数据的同步任务。

如果你在实操过程中遇到报错，或者有更复杂的业务场景（如多表关联分页），欢迎访问 N8N大学 (n8ndx.com)，这里有更多硬核的实战案例等你来挖。

记住，自动化不是为了偷懒，而是为了把时间花在更有价值的事情上。Happy Building!