上周我在折腾一件事——让 Harness Agent 帮我查生产数据库的慢查询。你别说这事听起来简单真正干起来就发现Agent 会写代码但它不知道怎么连数据库啊。它又没长手总不能自己去装个 MySQL Client 再敲 SQL 吧这就是 MCP 的用武之地了。上一篇我写了怎么手搓一个文件操作的 MCP Server今天咱们整点更实用的——数据库 MCP Server让 Agent 通过自然语言直接查数据库、生成报表。我那次的需求是这样的有个线上服务最近响应变慢了我想知道哪些 SQL 在拖后腿。以前的做法是登录跳板机 → 连 MySQL → 敲SHOW PROCESSLIST→ 翻slow_query_log→ 复制到本地 → 分析。一整套下来至少半小时中间还容易被打断回来忘了自己查到哪了。有了数据库 MCP Server 之后我在 Harness 里直接说了一句帮我查一下 production 库过去 24 小时的慢查询按执行次数倒排给我一份摘要。然后就去倒咖啡了。回来的时候Agent 已经把结果整理好了还补了一句发现order_list表有个全表扫描建议加索引。笑死比我 DBA 同事还积极。先说怎么搭这个数据库 MCP Server。其实思路很简单MCP 本质上是一个标准化的工具调用协议你暴露给 Agent 的每个工具Tool就是一个它可以调用的函数。数据库 MCP 说白了就是把 SQL 查询封装成 Tool。我选了 Python 的mcp库来搭代码量不大。核心就三个东西connect连数据库传入连接串就行。我用的是 MySQL但 PostgreSQL、SQLite 都一个套路。query执行 SQL 并返回结果。这里有个坑——我第一次跑的时候直接把原始 SQL 执行能力暴露给了 Agent。结果 Agent 来了一句SELECT * FROM users把 50 万行记录全拉回来了。好家伙差点把我数据库搞崩。所以一定要加安全限制默认只允许SELECT禁止DELETE、DROP、UPDATE。而且查询结果要做截断比如最多返回 100 行。describe让 Agent 先看表结构再决定查什么。这个特别重要——Agent 又不认识你的数据库你不给它看SHOW TABLES和DESCRIBE的结果它怎么知道该查哪张表有意思的是我第一次设计这个 Tool 列表的时候觉得三个够用了。结果真用起来发现还差一个——ask_confirm。Agent 查完数据想干点什么的时候让它先问一句我要执行 XX 操作确认吗。不然哪天它自己给自己开了个DROP DATABASE的权限那就真·灾难了。说到这个我踩过一个更深的坑。一开始我把数据库密码写死在 MCP Server 的配置文件里心想反正就我一个人用。结果有一天我让 Agent 去查数据它顺手把配置文件和密码一起写进了日志——然后日志被同步到了团队群里。同事在群里问ReleaseU你的数据库密码是Abcd1234吗我……所以密码一定要走环境变量走密钥管理服务不要写死在代码里。MCP Server 的配置模板里支持从环境变量读取这个习惯一定要养成。再说说报表生成。单纯查数据只是第一步真正爽的是让 Agent 把数据整理成报表。我写了一个generate_report的 Tool给它传 SQL 和报表格式它自动跑查询、汇总数据、生成 Markdown 表格。比如按天统计过去一周的订单量生成一个趋势报表。Agent 会先describe看表结构发现orders表有created_at和amount字段然后自己拼 SQLSELECT DATE(created_at) AS day, COUNT(*) AS order_count, SUM(amount) AS total_amount FROM orders WHERE created_at NOW() - INTERVAL 7 DAY GROUP BY DATE(created_at) ORDER BY day;然后跑出来格式化成一个表格最后还加了一句周三订单量最高周六最低建议检查周末的运营活动。嘿还能当半个运营分析师用。不过说实话现阶段数据库 MCP 也不是什么都好。有几个问题我必须要提第一是 Agent 的 SQL 水平参差不齐。我用 GPT-4 和 DeepSeek 分别试过同一个需求——查一下过去一个月每个用户的复购率。GPT 写出来的 SQL 逻辑是对的但嵌套了四层子查询跑起来慢得要死。DeepSeek 倒是简洁但搞混了COUNT(DISTINCT ...)和COUNT(...)的区别。所以如果你要上生产环境建议给 Agent 加一个 SQL Review 的中间层或者限制它只能查预定义的视图别直接裸查原表。第二个问题是结果的可视化。Agent 能给你 Markdown 表格但你要是想要一张折线图或者柱状图它目前还做不到。我现在的做法是让 Agent 把数据导出成 CSV然后我再丢给其他工具去画图。这个环节如果能打通体验会更完整。第三个是连接管理。多个 Agent 同时连同一个数据库连接池怎么管理长连接还是短连接我现在是每个请求新建连接用完后关闭但高频场景下效率不高。这块还在摸索中。总的来说数据库 MCP 是我目前觉得实用性最高的一个方向。它把 Agent 的能力从写代码延伸到了取数据、分析数据——这其实是很多日常工作里最耗时的环节。你猜怎么着我写完这篇的时候那个 DBA 同事刚好路过看到我在让 Agent 查慢查询问我这是什么工具。我说完他沉默了两秒然后说那你把我分析慢查询的活儿也干了吧。我……那你的工资分我一半他没接话走了。但我知道他回去肯定也在偷偷搭 MCP Server 了。下一篇咱们整 GitHub MCP——让 Agent 自己提 PR、做 Code Review、管 Issue一条龙自动化。你准备好把代码审查也交给 Agent 了吗评论区聊聊你是敢让 Agent 提 PR 的那种人还是觉得这件事得我自己来