引言：为什么你的数据流总是莫名其妙报错？
笔者在 N8N大学 做了这么多年的低代码自动化咨询，发现一个很有意思的现象：90% 的 n8n 新手在连接 MySQL 数据库时，节点配置看起来都完美无缺，但一跑数据就报错。要么是字段对不上，要么是数据类型莫名其妙变成了字符串。
这就像你精心准备了一桌菜，结果发现筷子拿成了勺子。今天，我就把我在 n8n 连接 MySQL 时踩过的数据类型转换与字段映射的坑，原原本本地复盘一遍。这不是官方文档的复读机，而是真刀真枪的实战经验。
场景导入：看似简单的“SELECT *”其实暗藏杀机
很多同学以为，n8n 连接 MySQL 就是填个 IP、账号密码，然后写个 SQL 语句就完事了。事实上，当你从 MySQL 节点输出数据，准备在下一个节点（比如 HTTP Request 或 Set 节点）处理时，经常会遇到这样的尴尬：
- 数据全变成了字符串： 明明数据库里是
INT或TIMESTAMP，到了 n8n 里全成了带引号的文本，导致后续做数学计算或日期比较时直接报错。 - 字段名大小写混乱： 数据库里是
user_id，n8n 里自动变成了User ID或者user_Id，导致 JSON 路径引用找不到。 - 布尔值被“伪装”：
TINYINT(1)的 0 和 1，经常被误判为字符串或数字，导致逻辑判断失效。
这些坑如果不填平，你的自动化流程就是个随时会爆炸的定时炸弹。
核心实操：如何精准拿捏字段映射与类型
在 n8n 中，MySQL 节点 的输出不仅仅是数据，更是一个结构化的 JSON 对象。理解这一点，是解决所有映射问题的关键。
第一步：理解“输出”与“映射”的本质
当你使用 MySQL 节点 执行查询时，n8n 会将每一行数据封装成一个 Item。此时，字段名的处理取决于你是否开启了 “Raw Queries”（原始查询） 模式。
避坑点： 如果你直接写 SELECT * FROM users，n8n 默认会尝试将数据库列名标准化（例如转为驼峰式）。如果你想保留原样，必须在 SQL 语句中使用别名，或者使用 Raw 模式。
例如，为了确保字段名完全可控，建议这样写：
SELECT
id as user_id,
name as user_name,
created_at
FROM users这样在 n8n 的输出中，你就能精准通过 user_id 和 user_name 引用数据，而不是去猜 n8n 给你转成了什么格式。
第二步：搞定数据类型的“自动转换”
这是最容易踩坑的地方。n8n 的 MySQL 节点 依赖底层的 Node.js 数据库驱动（通常是 mysql2）。默认情况下，驱动程序可能会为了“安全”将所有非文本数据都转为字符串。
如果你需要进行严格的类型判断（比如判断金额是否大于 100），在 MySQL 节点 之后，强烈建议紧跟一个 Set 节点（或 Edit Fields (Set) 节点） 进行手动类型转换。
操作步骤：
- 在 MySQL 节点 后添加一个 Set 节点。
- 在字段配置中，选择你需要转换的字段（例如
amount）。 - 在值（Value）处，不要直接引用
={{$json.amount}}，而是使用转换函数：
={{parseFloat($json.amount)}}对于日期类型，同样的逻辑：
={{new Date($json.created_at)}}虽然这看起来多了一步，但它能保证后续流程中数据类型的绝对一致性，避免了 90% 的逻辑错误。
第三步：处理复杂的 JSON 结构
MySQL 5.7 以上版本支持 JSON 类型字段。n8n 读取时，有时会把 JSON 对象当成字符串读出来，导致你无法直接引用内部属性。
解决方案： 在 Set 节点 中，使用 JSON.parse() 进行解析。
={{JSON.parse($json.json_column)}}但请注意，如果该字段已经是对象格式（直接从数据库驱动中解析好了），再次 parse 会报错。因此，处理前务必先用 Debug 节点 查看一下数据结构。
避坑指南：实战中的 3 个致命细节
除了基础的映射，以下这三个细节是我在 N8N大学 教学中反复强调的：
1. NULL 值的处理
MySQL 中的 NULL 在 n8n 中会显示为空字符串 "" 还是真正的 null？这取决于驱动配置。如果在 n8n 中引用了为 null 的字段，可能会导致流程报错。
建议： 在 Set 节点 中，默认给字段赋一个安全值：
={{$json.field || '默认值'}}2. 数据库编码问题（UTF8mb4）
如果你的 MySQL 表是 utf8mb4 编码，而 n8n 连接配置未指定，读取中文字符或 Emoji 时可能会出现乱码。在 n8n 的 MySQL 节点配置中，确保在“连接参数（Connection Parameters）”里添加字符集设置：
{"charset": "UTF8MB4"}3. 批量插入时的类型陷阱
当使用 MySQL 节点 进行批量插入（Insert Multiple）时，如果某个字段在第一行数据中是字符串，而第二行是数字，n8n 可能会因为类型不一致而报错。
最佳实践： 在插入前，使用 Set 节点 统一将所有需要插入的数据格式化为数据库期望的类型，不要依赖 n8n 的自动推断。
FAQ 问答
Q1: 为什么我的 MySQL 节点输出全是空的？
A: 通常是因为 SQL 语句语法错误，或者数据库连接超时。请先在 MySQL 客户端执行同样的 SQL 确认可行。如果 SQL 正确，检查 n8n 的日志（Logs），看是否有连接拒绝的错误。另外，确保你的 n8n 服务器白名单包含了 MySQL 数据库的 IP。
Q2: 如何在 n8n 中执行复杂的 SQL 脚本（包含变量）？
A: 不要直接拼接字符串，容易导致 SQL 注入且难以维护。在 n8n 的 MySQL 节点 中，使用 “从输入字段映射” 模式。在 SQL 语句中使用 ? 作为占位符，然后在下方的“参数（Parameters）”中映射对应的字段值。
Q3: n8n 能处理 MySQL 的存储过程吗？
A: 可以。在 MySQL 节点 的操作类型中选择“执行存储过程（Execute Stored Procedure）”，然后输入存储过程名称和参数（如果有）。注意存储过程的输出结果可能需要特殊处理，n8n 通常只返回第一个结果集。
总结与资源
n8n 连接 MySQL 并不难，难的是对数据流转过程中类型的掌控。记住一个原则：不要完全信任 n8n 的自动类型推断。在关键节点后使用 Set 节点 显式定义数据类型，是写出健壮自动化流程的核心技巧。
如果你在处理遗留系统或老旧的 MySQL 版本，遇到更棘手的编码或驱动问题，欢迎在 N8N大学 的社区留言，笔者会挑选典型案例进行深度解析。保持好奇，持续折腾！
