为什么使用了 n8n 之后，会觉得惊喜？
因为使用他实在太方便了，但让这里的方便不单是本地部署、升级上的方便（dify 要启动 7 个服务，coze 要启动 9 个服务，而 n8n 一个服务就搞定了），而是他整体的便利性。例如他提供的 5000+ 模板方便创建工作流，还有他集成了 400+ 应用快速实现某些功能，等等这些都让 n8n 便的流行。
今天就以 n8n 集成 MySQL 数据库实现自然语言的查询为例，给大家演示一下他的便捷之处。
如下工作流，我们就实现了自然语言直接操作 MySQL 数据库的功能：
核心实现
要实现这个功能的核心有两个：
- 使用 AI Agent 生成 MySQL 语句。
- 使用 n8n 提供的 MySQL 应用插件执行 MySQL，并返回结果。
简单吧，要知道我们使用 dify 或 coze 是需要通过 mcp 调用方式的方式，或者是安装插件的方式才能实现 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
FROMresume r
JOIN interview i ON r.id = i.rid
LEFT JOIN offer o ON r.id = o.rid
WHEREr.name = '张三'AND i.interview_time >= '2025-09-23'
ORDER BYi.interview_time DESC;
尽管我们这样写提示词，但 n8n 生成的结果依然会有特殊字符，此时 AI Agent 生成的结果我们可以使用正则表达式处理之后，再让 MySQL 组件进行执行才行，如下图所示：
这样我们就实现 n8n 直接查询数据库的功能了。
小结
关于提示词的文件读取问题，我们可以提前将提示词上传到 Docker 的目录中，使用 n8n 文件读取组件直接从目录中读取即可。当然如果数据库结构是可变的，我们还可以使用另外一个工作流，每次先查询当前数据库的数据结构，然后把最新的数据结构作为系统提示词给到 AI Agent，这样就能生成更精准的、动态的 SQL 语句了。
本文已收录到我的技术小站 www.javacn.site，其中包含的内容有：Spring AI、Spring AI Alibaba、LangChain4j、Dify、Coze、N8N、智能体（AI Agent）、MCP、Function Call、RAG、向量数据库、Prompt、多模态、向量数据库、嵌入模型、AI 常见面试问题等内容。
![[PaperReading] Qwen2-VL: Enhancing Vision-Language Model’s Perception of the World at Any Resolution](http://pic.xiahunao.cn/[PaperReading] Qwen2-VL: Enhancing Vision-Language Model’s Perception of the World at Any Resolution)
![[PaperReading] MemGPT: Towards LLMs as Operating Systems](http://pic.xiahunao.cn/[PaperReading] MemGPT: Towards LLMs as Operating Systems)
