作为 N8N大学 的首席主编，笔者见过太多朋友在跑自动化流程时，被“数据库连接超时”这个问题折磨得死去活来。特别是当你的 n8n 工作流要处理成千上万条数据，或者连接的是阿里云、腾讯云上那些内网数据库时，网络抖动、防火墙策略、数据库负载稍高，连接就会断掉。
如果你正盯着屏幕上那个红色的 Connection timeout 错误发愁，别急着去改代码。今天，笔者就带你硬核拆解 n8n 的重试机制，用大白话讲透如何配置，让你的自动化流程从此拥有“金刚不坏之身”。
为什么你的数据库连接总是超时？
在配置重试之前，我们得先搞清楚“敌人”是谁。数据库连接超时通常不是 n8n 本身的锅，而是外部环境的锅。
最常见的场景有三种：
- 网络抖动</strong：云数据库和 n8n 服务器之间的网络不是永远稳定的，偶尔丢包很正常。
- 数据库负载过高：连接池满了，数据库拒绝了新的连接请求。
- 防火墙策略：某些云厂商的安全组策略会限制长时间空闲的连接。
如果你的流程里有一个 MySQL 节点或者 Postgres 节点，一旦报错，整个工作流就会中断。这时候，重试机制 就是你的救命稻草。
n8n 核心重试机制：节点配置详解
很多人不知道，n8n 的重试配置其实藏在每个具体节点的“设置”里，而不是全局配置。这既是优点（灵活），也是缺点（容易被忽略）。
以最常用的 MySQL 节点为例，当你点击节点进入配置界面时，不要只盯着 SQL 语句，右上角有个 “Settings” (设置) 选项卡，点进去，里面藏着宝藏。
1. 开启重试开关 (Retry On Fail)
这是最基础的操作。在 Settings 选项卡中，你会看到 Retry On Fail 这个参数。默认情况下，它是关闭的。你需要把它打开。
一旦开启，当 n8n 遇到网络错误、超时等临时性故障时，它不会立即抛出错误停止工作流，而是会等待一段时间后再次尝试连接。
2. 关键参数配置 (Time & Retry Count)
光开启还不够，配置必须合理。这里有两个核心参数：
- Wait Time (等待时间)：每次重试之间的间隔时间（单位：毫秒）。
笔者建议：对于数据库连接，初始等待时间设置在 2000ms (2秒) 左右比较合适。太短了数据库还没缓过劲来，太长了影响效率。 - Retry Count (重试次数)：最多尝试多少次。
笔者建议：不要设置得无限大，否则如果配置错了（比如密码错误），它会无限循环浪费资源。通常 3 到 5 次 足够覆盖大多数网络波动。
配置示例：假设你的数据库偶尔卡顿，你可以设置 Wait Time: 3000，Retry Count: 5。这意味着如果连接失败，n8n 会等待 3 秒再试，一共试 5 次。
3. 超时时间 (Timeout)
除了重试，我们还得控制“单次连接”的耐心。在 MySQL 或 Postgres 节点的主配置里，通常有一个 Connect Timeout 或类似的参数。
默认值往往比较小（比如 10000ms，即 10 秒）。如果你的数据库查询很慢，或者网络延迟高，建议把这个值适当调大，比如 30000ms (30秒)。这给了数据库更多的时间来响应，减少了因“等待太久”而触发重试的概率。
进阶技巧：使用“兜底”逻辑处理失败
虽然 n8n 的重试机制很强大，但并没有 100% 的保证。如果重试了 5 次还是失败怎么办？工作流还是会报错。
这时候，我们需要引入 Error Trigger (错误触发器) 节点。这是一个非常实用的“兜底”机制。
你可以这样设计你的工作流：
- 主流程：执行数据库操作（配置了重试机制）。
- 在主流程节点上，连接一个 Error Trigger 节点。
- 当重试耗尽依然失败时，Error Trigger 会被激活。你可以在里面写一个逻辑，比如发送一条钉钉/飞书通知给管理员：“数据库又挂了，赶紧看看！”。
这样一来，即使系统崩溃，你也能第一时间知情，而不是等到用户投诉才发现流程断了。
避坑指南：配置重试的 3 个常见误区
在 N8N大学 的实战案例中，我们发现很多同学在配置重试时容易踩坑。这里笔者必须提醒你：
误区一：盲目增加重试次数
有些同学觉得重试次数越多越好，直接设成 100 次。这是大忌！
如果是“密码错误”或“表不存在”这种配置错误，重试 100 次也是徒劳，只会疯狂消耗你的服务器 CPU 和日志空间。重试机制只针对“临时性故障”（如网络波动）。
误区二：忽略了“事务”问题
如果你的数据库操作涉及事务（Transaction），重试可能会带来数据一致性问题。
比如：你的 SQL 语句是“先扣库存，再生成订单”。如果扣库存成功了，但生成订单时网络超时触发了重试，可能会导致库存被扣了两次。
解决方案：对于涉及核心资金或库存的流程，尽量确保 SQL 语句是幂等的，或者在 n8n 中使用更复杂的事务管理节点。
误区三：没有区分“连接错误”和“查询错误”
n8n 的重试机制是“一刀切”的，它会对所有报错进行重试。
如果你的 SQL 语法写错了（比如少了个逗号），重试 100 次也没用。
建议：在开发阶段，先关闭重试，快速排查语法错误；上线稳定运行后，再开启重试应对网络波动。
FAQ：关于 n8n 数据库重试的常见问题
Q1: 设置了重试，但日志里没有看到重试记录，是什么原因？
这说明 n8n 遇到的错误可能不是“网络超时”类的可重试错误。n8n 内部有一个错误分类列表，只有特定的错误（如 ECONNRESET, ETIMEDOUT）才会触发重试。如果是权限拒绝（EACCESS）或语法错误，n8n 会直接报错，因为它知道重试也没用。
Q2: n8n 的重试机制是全局生效的吗？
不是。n8n 的重试配置是基于 单个节点 的。你需要对你工作流中的每一个数据库操作节点（如 MySQL, Postgres, MongoDB）单独配置。如果你的工作流很长，建议统一设置，避免遗漏。
Q3: 除了节点自带的重试，n8n 还有别的重试方式吗？
有的。如果你使用的是 HTTP Request 节点连接 RESTful API 接口的数据库，还可以利用 HTTP Request 节点自带的重试设置。此外，高级用户可以使用 n8n 的“Wait”节点配合循环逻辑来实现更复杂的重试策略，但这通常需要编写表达式。
总结与资源
数据库连接超时是自动化流程中的“慢性病”，虽然不致命，但很烦人。通过合理配置 n8n 节点的 Retry On Fail、Wait Time 和 Retry Count，你可以解决 90% 的偶发性连接问题。
记住，工具是为人服务的。不要让配置成为负担，理解原理才能灵活运用。
如果你想了解更多关于 n8n 高级错误处理的实战案例，欢迎访问 N8N大学 (n8ndx.com)，这里有更多硬核的自动化避坑指南等你来学。
