场景导入：别再把时间浪费在导出 CSV 上了

上周，我的一位学员在社群里吐槽：为了把 MySQL 数据库里的订单数据同步到 Google Cloud SQL，他每天都要手动导出 CSV，再导入到 Google Cloud。这不仅耗时，还容易出错。他问我：“有没有办法让数据库之间‘自动对话’？”

当然有。作为 N8N大学 的首席主编，我处理过无数次类似的数据迁移需求。相比于编写复杂的 Python 脚本或购买昂贵的 ETL 工具，使用 n8n 进行数据库集成，不仅成本低，而且可视化流程让维护变得极其简单。

今天，我就以一次实战数据迁移为例，带你记录从本地 MySQL 到 Google Cloud SQL 的完整迁移过程。这不仅仅是技术操作，更是一次自动化思维的升级。

准备工作：硬核前置条件

在开始之前，请确保你已具备以下条件。这是实战的基础，缺一不可：

• 运行中的 n8n 实例：可以是 Docker 部署，也可以是云服务器上的 n8n。
• 源数据库：本地或远程的 MySQL 数据库（我们称之为 A 库）。
• 目标数据库：Google Cloud SQL 实例（我们称之为 B 库）。
• 数据库凭证：A 库和 B 库的 Host、Port、User、Password、Database Name。
• 网络连通性：确保 n8n 服务器能同时访问 A 库和 B 库（Google Cloud SQL 通常需要配置公网 IP 或白名单）。

笔者提示： Google Cloud SQL 默认通常只允许特定 IP 访问。请务必在 Google Cloud Console 的“连接安全性”中，将运行 n8n 的服务器 IP 加入白名单，否则后续步骤会直接报错。

核心实操：构建数据同步管道

本次实战我们将分三个核心步骤进行：读取源数据、清洗与转换、写入目标库。全程使用 n8n 的原生节点。

步骤一：读取 MySQL 源数据 (MySQL Node)

首先，我们需要建立与源数据库的连接，并读取需要迁移的数据。

1. 在 n8n 工作流中添加第一个节点：MySQL。
2. 点击节点，选择“Execute a SQL Query”（执行 SQL 语句）模式。
3. 在 Credentials（凭证）中配置你的源数据库连接信息。如果还没创建，点击旁边的“+”号新建。
4. 在 Query 字段中输入 SQL 语句。例如，迁移订单表：SELECT * FROM orders WHERE created_at > '2023-01-01'。

关键点： 建议先在数据库管理工具中测试 SQL 语句，确保返回的数据结构符合预期，避免在 n8n 中调试。

步骤二：数据清洗与格式转换 (Set/Function Node)

源数据和目标数据的结构往往不完全一致，这一步至关重要。

1. 添加一个 Set 节点（如果只是简单的字段映射）或 Function 节点（如果需要复杂处理）。
2. 连接上一步的 MySQL 节点。
3. 在 Set 节点中，你可以重命名字段，或者将某些字段转换为 Google Cloud SQL 需要的格式（例如，将字符串格式的日期转换为 Date 对象）。
4. 硬核技巧： 如果数据量大，利用 Set 节点的“Keep Only Set”功能，只保留目标表需要的字段，减少传输负担。

步骤三：写入 Google Cloud SQL (MySQL Node)

这是最后一步，将处理好的数据推送到 B 库。

1. 再次添加一个 MySQL 节点，这次用于写入。
2. 在 Credentials 中创建一个新的凭证，指向你的 Google Cloud SQL 数据库。
3. 选择操作模式：Insert（插入）。
4. 在 Table 字段填入目标表名（例如 orders_backup）。
5. 映射字段：确保 n8n 输入的字段名与目标表的列名一一对应。

连接顺序应为：MySQL (Read) -> Set -> MySQL (Write)。

避坑指南：实战中的血泪教训

看似简单的流程，在实际部署中往往会遇到意想不到的报错。以下是我在实战中总结的两个高频坑点：

坑点 1：Google Cloud SQL 的 SSL/TLS 强制连接

Google Cloud SQL 默认要求使用 SSL 连接，而 n8n 的 MySQL 节点默认配置可能不包含 SSL 证书，导致连接被拒绝。

解决方案：

• 在 n8n 的 MySQL 凭证配置中，找到 SSL 选项。
• 你需要下载 Google 提供的服务器证书（Server CA Certificate），并将其内容填入 n8n 凭证的“CA Certificate”字段中。
• 如果你的 n8n 版本支持，可以直接勾选“SSL”开关，选择“Amazon RDS”或通用 SSL 模式尝试连接。

坑点 2：数据类型不匹配导致的写入失败

MySQL 的 TEXT 类型在 Google Cloud SQL 中可能被识别为不同的类型，或者时间戳格式（Timestamp）在迁移时出现时区偏差。

解决方案：

在“步骤二”中，使用 Function 节点显式转换数据类型。例如，使用 JavaScript 代码将时间戳统一格式化为 YYYY-MM-DD HH:MM:SS 字符串，确保数据库能正确解析。

FAQ 问答

Q1: 这种方式适合实时数据同步吗？

适合。你可以将 n8n 设置为定时触发（例如每 5 分钟一次），或者使用 Webhook 节点监听源数据库的变更（如果源库支持触发器或 CDC）。对于大多数业务场景，近实时同步已经足够。

Q2: 数据量达到百万级，n8n 能处理吗？

可以，但需要优化。不要一次性读取所有数据。建议在 MySQL 节点中使用 LIMIT 和 OFFSET 进行分页读取，或者在 SQL 查询中添加时间范围过滤，分批次处理。N8N大学 之前写过关于大数据量处理的专门教程。

Q3: 迁移过程中如果断网了怎么办？

n8n 具有重试机制。你可以在每个节点的设置中配置“重试”策略。如果是长时间迁移任务，建议开启“继续运行”模式，即使某个批次失败，也不会导致整个工作流崩溃。同时，利用 Set 节点记录处理进度，便于断点续传。

总结与资源

通过 n8n 集成 Google Cloud SQL，我们不仅完成了一次数据迁移，更构建了一条可复用的数据管道。相比于传统的脚本，n8n 的可视化界面让数据流向一目了然，维护成本极低。

如果你正被重复的数据搬运工作困扰，不妨试试这个方案。自动化不仅仅是工具的替换，更是思维方式的解放。

相关资源推荐：

• N8N大学官方文档：n8n 节点参数详解
• Google Cloud SQL 连接最佳实践