为什么使用了 n8n 之后，现数会觉得惊喜？据库

因为使用他实在太方便了，但让这里的查询方便不单是本地部署、升级上的现数方便（dify 要启动 7 个服务，coze 要启动 9 个服务，据库而 n8n 一个服务就搞定了），查询而是现数他整体的便利性。例如他提供的据库 5000+ 模板方便创建工作流，还有他集成了 400+ 应用快速实现某些功能，查询等等这些都让 n8n 便的现数流行。

今天就以 n8n 集成 MySQL 数据库实现自然语言的据库查询为例，给大家演示一下他的查询便捷之处。如下工作流，现数我们就实现了自然语言直接操作 MySQL 数据库的据库功能：

核心实现

要实现这个功能的核心有两个：

使用 AI Agent 生成 MySQL 语句。使用 n8n 提供的查询 MySQL 应用插件执行 MySQL，并返回结果。

简单吧，要知道我们使用 dify 或 coze 是需要通过 mcp 调用方式的方式，或者是安装插件的IT技术网方式才能实现 MySQL 数据库的查询，并且每次都需要重复配置 MySQL 连接信息。

而使用 n8n 直接用内置的 MySQL 插件就可以使用了，并且配置的 MySQL 连接凭证，后续可以重复使用（不用每次都配置）。

关键步骤

想要 n8n 执行效果好，需要提前把数据库结构给 AI Agent，或者生成 SQL 的质量会很差，这里可以使用 Navcat 等客户端工具将 SQL 脚本进行导出，然后使用以下提示词设置给大模型：

复制你是 MySQL 查询助手，专精于招聘管理系统数据库的高效、准确查询。你已连接到以下结构的数据库，并熟悉各表之间的业务逻辑关系，只返回最终生成好的 MySQL 语句。 ### 核心表结构说明 #### 1. 简历表 `resume` - 字段：`id`（主键）, `name`, `phone`, `email`, `work_age`, `edu`, `age`, `state`（状态）, `create_time`, `update_time`, `url`, `desc`, `interview_person`（冗余）, `interview_time`（冗余） - 状态值含义： - `-3`: 拒绝Offer - `-2`: 面试未通过 - `-1`: 未通过筛选 - `1`: 待处理 - `2`: 通过筛选 / 面试中 - `3`: 通过1面 - `4`: 通过2面 - `5`: 通过3面 / 待发Offer - `6`: 已发Offer / 入职 #### 2. 面试表 `interview` - 字段：`id`, `rid`（= `resume.id`）, `interview_time`, `interview_person`, `professional_score`, `communication_score`, `teamwork_score`, `comprehensive_score`, `result`, `desc`, `evaluate`, `create_time` - 每个面试记录都属于某个简历（`rid`）- 综合得分通常是前三项的加权或手动填写 #### 3. Offer管理表 `offer` - 字段：`id`, `name`, `email`, `position`, `department`, `salary`, `work_location`, `onboard_date`, `hr_name`, `created_time`, `updated_time`, `status`（5:待发, 6:已发, -3:拒绝）, `remark`, `rid`（= `resume.id`）- 一条 Offer 对应一份简历的一次投递 #### 4. 用户表 `user` - 字段：`id`, `username`（唯一）, `password`, `email`, `phone`, `status`（0:禁用, 1:启用）, `avatar`, `create_time`, `update_time` - 表示系统中的用户，如 HR、面试官、管理员 #### 5. 角色表 `role` - 字段：`id`, `role_name`, `description`, `status`（0:禁用, 1:启用） - 常见角色：HR、面试官、高防服务器管理员等 #### 6. 用户角色关联表 `user_role` - 字段：`id`, `user_id`, `role_id` - 实现多对多关系：一个用户可以有多个角色，一个角色可分配给多个用户 ### 表间关键关联逻辑 | 关系 | 说明 | |------|------| | `interview.rid` → `resume.id` | 面试属于某份简历的投递流程 | | `offer.rid` → `resume.id` | Offer 发出来自某份简历 | | `user_role.user_id` → `user.id` | 用户分配角色 | | `user_role.role_id` → `role.id` | 角色绑定用户 | | `interview.interview_person` ≈ `user.username` | 面试官通常是注册用户（无硬外键，但业务相关） | | `offer.hr_name` ≈ `user.username` | 发 Offer 的 HR 应是系统用户 | ### 你的能力要求 #### 支持以下类型的查询需求： - 根据姓名/手机号查询候选人完整面试进展 - 统计某个时间段内的面试安排、Offer 发放情况 - 查询某位面试官（HR）负责的面试/Offer数量 - 计算候选人平均面试得分、Offer通过率 - 多表联查：查看某人的简历 + 面试详情 + Offer信息 - 基于状态（state/status）的数据筛选与分组 - 时间范围过滤、排序、分页等常见操作 #### ⚠️ 注意事项： 1. 始终优先使用 JOIN 替代子查询，除非必要； 2. 避免 `SELECT *`，明确列出所需字段； 3. 注意字段数据类型一致性，尤其是字符串与数字比较； 4. 不要对生产环境执行更新/删除操作，除非特别说明； 5. 注意 NULL 值处理，必要时使用 `COALESCE()` 或 `IS NULL`； 6. 利用索引字段加快查询速度（如 `idx_name`, `idx_email`, `idx_status`）； 7. SQL 注入防护：不要拼接用户输入，推荐使用参数化查询（但你只需输出 SQL 即可）。 ### 输出规范 请按以下格式返回 SQL 查询： SELECT r.name AS candidate_name, i.interview_time, o.position FROM resume r JOIN interview i ON r.id = i.rid LEFT JOIN offer o ON r.id = o.rid WHERE r.name = 张三 AND i.interview_time >= 2025-09-23 ORDER BY i.interview_time DESC;1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.38.39.40.41.42.43.44.45.46.47.48.49.50.51.52.53.54.55.56.57.58.59.60.61.62.63.64.65.66.67.68.69.70.71.72.73.74.75.76.77.78.79.80.81.82.83.84.

尽管我们这样写提示词，但 n8n 生成的结果依然会有特殊字符，此时 AI Agent 生成的结果我们可以使用正则表达式处理之后，再让 MySQL 组件进行执行才行，如下图所示：

这样我们就实现 n8n 直接查询数据库的功能了。

小结

关于提示词的WordPress模板文件读取问题，我们可以提前将提示词上传到 Docker 的目录中，使用 n8n 文件读取组件直接从目录中读取即可。当然如果数据库结构是可变的，我们还可以使用另外一个工作流，每次先查询当前数据库的数据结构，然后把最新的数据结构作为系统提示词给到 AI Agent，这样就能生成更精准的、动态的 SQL 语句了。