别让“拼接SQL”毁了你的数据库：n8n自动化中的隐形炸弹
笔者在 N8N大学 社区混迹多年，见过太多新手在自动化流程中埋下“地雷”。最常见的一个，就是在使用 MySQL 节点时，习惯性地使用字符串拼接来构建 SQL 语句。
你可能觉得：“只是内部工具，跑个数据而已，哪有那么容易中招？” 但只要你的流程涉及外部输入（比如 Webhook 接收参数、表单提交），恶意用户就能通过精心构造的输入，让你的数据库“裸奔”。今天，笔者就结合一次真实的防御实战，手把手教你如何在 n8n 中使用参数化查询，彻底杜绝 SQL 注入风险。
什么是 SQL 注入？为什么在 n8n 中尤其危险？
简单来说，SQL 注入就是攻击者通过输入恶意数据，改变了你原本 SQL 语句的执行逻辑。
想象一下，你写了一个简单的查询语句：
SELECT * FROM users WHERE username = '" + inputs.username + "';如果用户老老实实输入 "admin"，SQL 就是正常的。但如果他输入 ' OR '1'='1 呢？你的 SQL 就变成了：
SELECT * FROM users WHERE username = '' OR '1'='1';这行代码会返回所有用户数据，因为 '1'='1' 永远为真。在 n8n 中，如果你不加处理直接将前端传来的参数拼接到 SQL 节点中，你的数据库就等于大门敞开。
实战开始：从错误的拼接转向安全的参数化
在 n8n 的 MySQL 节点中，官方其实早就为我们准备好了防御武器——“参数化查询”（Parameterized Query）。很多新手因为不熟悉，往往忽略了这个设置。
下面是我最近在一个电商订单同步流程中的实战记录。
第一步：搭建流程与识别风险点
我的流程很简单：Webhook 接收订单数据 -> MySQL 查询用户信息。
Webhook 传来的参数是 user_id。如果我使用传统的拼接方式，SQL 语句长这样：
SELECT * FROM orders WHERE user_id = {{ $json.user_id }}虽然 n8n 的表达式引擎有一定过滤作用，但为了保险起见，必须使用参数化查询。这不仅是防御黑客，也是防止脏数据（比如 ID 包含特殊字符）导致查询报错。
第二步：配置 MySQL 节点的关键参数
拖拽一个 MySQL 节点到画布，配置好数据库连接（Host, User, Password 等）。重点来了，在 SQL Query 部分：
- 不要直接写死值： 在输入框中，不要写
SELECT * FROM orders WHERE user_id = 123。 - 使用占位符： 写成
SELECT * FROM orders WHERE user_id = ?。这里的?就是占位符，告诉数据库：“这里将来会有一个参数，你别急着解析它。” - 切换模式： 在下方的设置中，找到 Use Parameterized Query（使用参数化查询）选项，确保它是 开启 状态（在某些版本中默认开启，但建议手动检查）。
第三步：正确处理参数数组
光写占位符还不够，你得告诉 n8n 这个参数从哪里来。在 n8n 的 MySQL 节点中，参数通常是通过数组传递的。
点击输入框旁边的“表达式”切换按钮（fx），或者在高级设置中找到 Query Parameters（查询参数）。
这里需要填写一个数组。如果你的 SQL 是 WHERE user_id = ?，那么参数数组就是：
[{{ $json.user_id }}]如果查询有多个条件，比如 WHERE user_id = ? AND status = ?，参数数组则对应为：
[{{ $json.user_id }}, "{{ $json.status }}"]注意： 参数的顺序必须与 SQL 语句中占位符 ? 的顺序完全一致。
对比实测：拼接 vs 参数化
为了让大家更直观地看到区别，笔者做了一个简单的对比测试（假设攻击者输入了恶意的 ID）：
| 攻击方式 | 字符串拼接 (危险) | 参数化查询 (安全) |
|---|---|---|
| 输入内容 | 1 OR 1=1 |
1 OR 1=1 |
| 最终 SQL | SELECT * FROM users WHERE id = 1 OR 1=1 |
SELECT * FROM users WHERE id = "1 OR 1=1" |
| 执行结果 | 返回所有数据 (数据泄露) | 查询 ID 为 "1 OR 1=1" 的记录 (通常为空，安全) |
看到区别了吗？参数化查询会将输入的整个字符串视为一个纯文本值，数据库绝不会将其解析为 SQL 命令。
避坑指南：实战中的两个细节
在 N8N大学 的社区里，我见过不少人即使开启了参数化查询，依然遇到了报错。通常是因为这两个细节没注意：
1. 数据类型陷阱
参数化查询对数据类型非常敏感。如果你的数据库字段是整型（INT），但 Webhook 传来的 user_id 是字符串格式（例如 "123"），某些严格的数据库驱动可能会报错。
解决方案： 在 MySQL 节点之前，加一个 Set 节点或 Function 节点，强制转换数据类型。
// Function 节点代码示例
const userId = parseInt($json.user_id);
return [{ json: { user_id: userId } }];2. IN 子句的写法
如果你想用一个参数查询多个 ID，比如 WHERE id IN (?)，直接传数组 [1, 2, 3] 可能会报错，因为某些 MySQL 驱动不支持直接将数组展开到单个占位符中。
解决方案： 对于复杂的 IN 查询，建议使用 CONCAT 函数或者动态生成占位符（如 ?, ?, ?）。最稳妥的方法是根据数组长度动态生成 SQL 字符串。
FAQ：关于 n8n MySQL 节点的常见疑问
Q1: 参数化查询会影响性能吗？
不会，反而会更好。 虽然预编译 SQL 语句需要一点点额外的开销，但数据库通常会缓存编译后的执行计划。当同样的查询结构重复执行时（这在自动化流程中非常常见），参数化查询的效率远高于每次重新解析拼接的 SQL。
Q2: 我的历史流程全是拼接 SQL，要全部重写吗？
强烈建议重写。 尤其是涉及外部输入（Webhook、API）的流程。你可以先从风险最高的几个流程开始改造。对于纯内部的、参数完全可控的静态查询，风险较低，但为了规范和可维护性，建议统一使用参数化。
Q3: n8n 的 MySQL 节点支持存储过程吗？
支持。 你可以在 SQL 输入框中直接调用存储过程，例如 CALL my_proc(?, ?)，并配合参数数组使用。但要注意存储过程内部的安全性，不要在存储过程内部进行动态 SQL 拼接（除非使用了 PREPARE 语句）。
总结与资源
SQL 注入是 Web 安全中最古老但也最有效的攻击手段之一。在 n8n 这种低代码工具中，我们往往专注于“连通性”，而忽视了“安全性”。
记住 N8N大学 给你的忠告：永远不要信任外部输入，永远使用参数化查询。 这不仅是一种技术规范，更是一种职业素养。希望这篇实战记录能帮你守住数据安全的底线。
