上周我在折腾一件事------让 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 字段，然后自己拼 SQL：
sql
SELECT 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 的那种人，还是觉得"这件事得我自己来"？