场景导入：别再盯着 Excel 复制粘贴了
你是不是经常遇到这种情况：每天早上第一件事，就是登录数据库跑个 SQL，把结果导出成 Excel，然后手动复制粘贴到邮件里发给老板？或者，你想根据数据库里的数据自动触发一些操作，比如给特定用户发优惠券，却卡在了“数据怎么取出来”和“数据怎么传给下一个节点”这两步上。
笔者在 N8N大学 混了这么多年，见过太多人把 n8n 当作一个简单的脚本工具，而不是一个强大的数据管道。今天这篇教程，我们就来硬核拆解 n8n 中最核心的玩法之一：**MySQL 节点查询结果映射到后续节点**。这不仅仅是简单的查询，更是从“数据提取”到“字段操作”的完整闭环。
搞懂了这套流程，你不仅能省去 90% 的人工复制工作，还能构建出真正智能的自动化工作流。废话不多说，直接开干。
准备工作：硬性条件检查
在开始配置工作流之前，请确保你手头有以下资源：
- 一个可用的 n8n 环境：可以是 n8n.cloud 的云端版本，也可以是本地或服务器部署的本地版本。
- 一个 MySQL 数据库：你需要知道数据库的 Host、Port、用户名和密码。
- 测试数据：为了演示，笔者建议在数据库中准备一张简单的表，例如
users表，包含id,name,email字段。
核心实操：三步搞定数据流转
我们将构建一个简单的工作流：从 MySQL 读取数据，提取特定字段，然后通过 HTTP 请求模拟发送数据。这涵盖了数据流转的 90% 场景。
步骤一：连接并查询 MySQL 数据
首先，在 n8n 画布中添加 MySQL 节点。
- 配置数据库凭证：点击“新建凭证”，输入你的数据库 Host、Database、User 和 Password。点击“连接测试”，确保状态显示“成功”。
- 编写 SQL 语句：在“Query”字段中输入
SELECT * FROM users。这里请注意，虽然生产环境建议做分页，但为了演示，我们先全量查询。 - 运行节点：点击“执行节点”。你会看到输出面板中出现了一个 JSON 数组，包含了数据库中的所有行数据。这是后续所有操作的源头。
笔者提示：第一次连接数据库时，如果连接失败，请检查防火墙是否放行了 3306 端口，以及数据库用户是否有远程连接权限。
步骤二：核心难点——数据映射与字段提取
这是最关键的一步。直接从 MySQL 获取的数据是“行”级别的集合，但后续节点往往需要“单条”数据或特定字段。
我们在 MySQL 节点后添加一个 Set 节点（或者更现代的 Code 节点，这里用 Set 讲原理更直观）。
在 Set 节点中，n8n 允许你定义输出的 Key 和 Value。但这里有个新手最容易踩的坑：
- 错误做法：直接在 Set 节点写死字段值，这会导致数据丢失。
- 正确做法：使用 表达式（Expression）。
点击 Set 节点的“Add Field”，输入字段名（如 target_email），然后点击旁边的“fx”按钮。在弹出的变量树中，找到 MySQL 节点的输出。路径通常类似：JSON -> 0 -> email。
重点来了：如果你想把所有用户的数据都传下去，直接添加 Set 节点是不够的。n8n 的默认行为是处理单条数据。如果你需要处理多条，你需要在 MySQL 节点后添加一个 Split Out 节点。
流程修正：
- MySQL 节点输出：包含 3 个用户的数组。
- 添加 Split Out 节点：它会把数组拆分成 3 个独立的 Item（数据行）。
- 添加 Set 节点：现在，针对每一个 Item，你可以通过
={{ $json.email }}这样的表达式来提取当前行的 email 字段。
步骤三：将数据传递给后续节点
有了 Split Out 和 Set 节点的处理，现在每一个 Item 都包含了我们需要的干净数据。
我们添加一个 HTTP Request 节点作为演示：
- Method: POST
- URL: 你的接收端地址（例如一个 Mock 的 Webhook 地址）
- Body Content Type: JSON
- Body: 这里是映射的终点。点击 Code Editor，输入如下 JSON 结构：
{
"send_to": "={{ $json.target_email }}",
"user_id": "={{ $json.id }}"
}这里的 {{ $json.target_email }} 就是上一步 Set 节点定义的字段。点击运行，你会发现 MySQL 里的每一条数据都被精准地映射到了 HTTP 请求的 Body 中。
避坑指南：实战中容易报错的细节
在 N8N大学 的社区里，关于 MySQL 映射的报错每天都在发生。以下是两个最常见的坑：
1. 时区问题导致的数据过滤错误
现象：查询昨天的数据，结果查出来是前天的，或者漏掉了一些数据。
原因：MySQL 服务器的时区与 n8n 运行环境的时区不一致。当 WHERE 子句涉及时间戳（TIMESTAMP）时，这种差异是致命的。
解决方案：在 MySQL 节点的“Additional Fields”中，找到“Timezone”选项。如果你的服务器在 UTC+8，就显式设置为 Asia/Shanghai 或 +08:00。不要依赖默认值。
2. 字段类型不匹配导致的映射失败
现象：在 Set 节点使用表达式提取数字 ID 时，后续节点报错提示“Expected String, got Number”。
原因：数据库里的 id 通常是整型（Integer），但某些 API 接口强制要求字符串。
解决方案：在表达式中进行强制类型转换。不要只写 {{ $json.id }}，而是写 {{ $json.id.toString() }}。或者在 SQL 查询阶段直接处理：`SELECT id AS string_id, ...`。笔者建议在 SQL 层处理，效率最高。
FAQ 问答
Q1：为什么我的 MySQL 节点查询不到数据，但数据库里明明有？
A：最常见的原因是凭证配置错误，或者 SQL 语句中指定的数据库名称（Database）与实际不符。另外，如果使用了云数据库（如阿里云 RDS），请检查白名单是否添加了 n8n 服务器的 IP 地址。
Q2：查询结果有几千条，n8n 运行很慢，甚至崩溃，怎么办？
A：这是典型的内存溢出问题。不要一次性查询所有数据。在 MySQL 节点的“Options”里，使用“Limit”限制每次查询的数量（如 100 条），然后配合 n8n 的“Loop Over”功能或者分页逻辑来处理。对于大数据量，建议在 SQL 层面就做好过滤，只拉取必要的数据。
Q3：如何将 MySQL 查询结果作为一行数据传递给 Python 或 Function 节点处理？
A：如果你不需要拆分行，只想把整个 JSON 数组传给下一个节点处理，不要加 Split Out 节点。直接在 MySQL 节点后连接 Function 节点。在 Function 节点中，通过 items[0].json 即可访问到完整的数组结构（注意：此时数组是嵌套在第一个 item 的 json 属性里的）。
总结与资源
n8n 的 MySQL 节点映射看似简单，实则涉及数据结构的转换和性能的权衡。掌握 Split Out 节点的使用时机，以及表达式的精准引用，是构建专业工作流的基础。
如果你想深入学习更多关于 n8n 数据处理的黑科技，欢迎访问 N8N大学 (n8ndx.com)。这里有更多实战案例和避坑指南等你来拿。记住，自动化不是为了炫技，而是为了把时间留给更有价值的思考。
