前面给大家普及MCP的基础知识，并且演示了浏览器自动化，数据采集等常用功能，今天给大家介绍一款超级重磅的生产力工具——PostgreSQL MCP

数据库大家都不陌生吧，这玩意儿平时都是dba在用，普通人不会sql语言没法用，但是现在不一样了，有了 PostgreSQL MCP 你可以用自然语言和数据库对话，直接打破了普通人使用数据库的最后一道屏障——SQL语言

对于DBA来说更是如虎添翼！！！

不仅如此，多个mcp协作，可以把你的一句话直接转化为最终结果，牛马也能体会到当领导的感觉，比如：

你有没有遇到过这种情况——

下午3点，老板发来消息：“上个月各渠道的用户留存数据，能不能给我整一下？”

你打开DBeaver，想了10秒钟先查哪张表，翻出来三个可能相关的表，写了两版SQL，跑了一遍发现JOIN的字段搞错了，改完再跑，把结果复制到Excel，整理格式——等你把表格发出去，1小时过去了。

如果你有PostgreSQL MCP，这件事的时间是：30秒。

---

01 / 什么是 PostgreSQL MCP？

MCP（Model Context Protocol）是Anthropic于2024年底发布的开放协议，核心作用是让AI模型以标准化方式连接外部工具和数据源。你可以把它理解为：给AI装了一根能插进任何设备的USB-C线。

PostgreSQL MCP，就是这根线的数据库接口。

它在PostgreSQL数据库和AI应用之间架了一座桥：AI不再只能看你粘贴过来的数据片段，而是可以直接访问数据库，理解表结构，自主构造并执行SQL，把结果以清晰的方式返回给你。

一句话：你用自然语言提问，AI负责写SQL、执行、解释结果。

---

02 / 市面上主流的 PostgreSQL MCP 方案

截至2025年底，PostgreSQL MCP已有多个成熟实现，定位不同，适合不同场景。

① 官方参考实现（@modelcontextprotocol/server-postgres）

由Anthropic开源，已于2025年归档停止维护。功能极简：只提供一个query工具，所有操作在只读事务中执行，外加数据库表结构（Schema）的自动暴露。适合快速上手和原型验证。

② Postgres MCP Pro（crystaldba/postgres-mcp）

目前功能最完整的DBA专用方案。由Crystal DBA团队开发，提供9个专业工具，涵盖索引调优、执行计划分析、数据库健康检查等高级功能。支持可读写的"无限制模式"和"受限只读模式"切换。

③ pgmcp（subnetmarco/pgmcp）

轻量级只读方案，侧重自然语言转SQL的体验，支持分页、全文搜索、多格式输出（表格/JSON/CSV），适合数据分析师和产品运营日常查询。

④ 云厂商专用方案

• Supabase MCP Server

  ：深度集成Supabase平台，支持Edge Functions、存储管理等云功能

• Neon MCP Server

  ：专为Neon Serverless PostgreSQL设计

• 阿里云 AnalyticDB PostgreSQL MCP

  ：对接阿里云数据仓库服务

---

03 / 核心功能详解

以功能最丰富的Postgres MCP Pro为例，逐一拆解其9个核心工具：

🔍 数据库结构探查

list_schemas — 列出实例中所有数据库模式

list_objects — 列出指定Schema中的所有对象（表、视图、序列、扩展）

get_object_details — 获取特定表的详细信息：列定义、数据类型、约束、索引

这三个工具组合，让AI在第一次接触你的数据库时就能"读懂"整体结构，后续所有操作都建立在真实元数据之上，而不是靠猜。

---

⚡ SQL执行

execute_sql — 执行SQL语句

支持两种模式：

• 受限模式（Restricted）

  ：只读事务 + 执行时间限制，适合生产环境查询

• 无限制模式（Unrestricted）

  ：完整读写权限，适合开发/测试环境

---

📊 性能分析三件套

explain_query — 获取SQL查询的执行计划（EXPLAIN ANALYZE）

不只是展示执行计划，还支持"假设索引模拟"：在不实际创建索引的情况下，预估添加某个索引后执行计划的变化。这依赖PostgreSQL的hypopg扩展实现。

get_top_queries — 基于pg_stat_statements数据，报告当前数据库中最慢的SQL查询及其统计信息（总执行时间、平均耗时、调用次数）

analyze_workload_indexes / analyze_query_indexes — 智能索引推荐

这是Postgres MCP Pro的明星功能。工具流程：

1. 从pg_stat_statements识别高消耗查询

2. 解析SQL结构，识别过滤条件、JOIN字段、GROUP BY、ORDER BY中的列

3. 枚举候选索引组合，用hypopg模拟效果

4. 用贪心算法找到成本效益最优的索引方案

5. 给出具体的CREATE INDEX建议

---

🏥 数据库健康检查

analyze_db_health — 一键全面体检，覆盖7个维度：

|
检查项
|
监控内容
|
| — | — |
|
索引健康
|
重复索引、未使用索引、无效索引
|
|
连接利用
|
当前连接数、max_connections使用率
|
|
缓冲区缓存
|
Buffer hit ratio，命中率低于95%会告警
|
|
Vacuum状态
|
表的autovacuum情况，事务ID环绕风险
|
|
序列监控
|
接近最大值的序列，防止溢出
|
|
复制延迟
|
主从延迟监控
|
|
约束验证
|
外键约束一致性检查
|

---

04 / 安装与配置

以 Postgres MCP Pro 为例，演示完整配置过程。

前置条件

- Python 3.10+ 
uv（Python 包管理器）
运行中的 PostgreSQL 实例（建议版本 13-17）
可选：pg_stat_statements 扩展（索引调优功能必需）




hypopg 扩展（假设索引模拟必需）

启用推荐扩展（在PostgreSQL中执行）：

-- 启用查询统计 

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

-- 启用假设索引模拟




CREATE EXTENSION IF NOT EXISTS hypopg;

在 postgresql.conf 中启用 pg_stat_statements：

shared_preload_libraries = 'pg_stat_statements' 




pg_stat_statements.track = all

Claude Desktop 配置

编辑 claude_desktop_config.json（路径：~/Library/Application Support/Claude/ 或 %APPDATA%\Claude\）：

{ 

"mcpServers": {

"postgres-mcp-pro": {

"command": "uvx",

"args": [

"postgres-mcp",

"--access-mode=restricted"

],

"env": {

"DATABASE_URI": "postgresql://readonly_user:password@localhost:5432/your_database"

}

}

}




}

关键参数说明：

• --access-mode=restricted

  ：只读模式，生产环境强烈推荐

• --access-mode=unrestricted

  ：读写模式，仅限开发测试

• DATABASE_URI

  ：使用最小权限账号，生产环境专用只读账号

快速入门版（官方参考实现）

如果只是快速体验，用官方包即可（注意该包已停止维护，仅建议测试用）：

{ 

"mcpServers": {

"postgres": {

"command": "npx",

"args": [

"-y",

"@modelcontextprotocol/server-postgres",

"postgresql://readonly_user:password@localhost:5432/mydb"

]

}

}




}

WorkBuddy / Cursor / Windsurf 配置

在 MCP 配置界面，找到或新增 MCP Server 条目，填入以下内容（以 Cursor 为例）：

{ 

"mcpServers": {

"postgres": {

"command": "uvx",

"args": ["postgres-mcp", "--access-mode=restricted"],

"env": {

"DATABASE_URI": "postgresql://用户名:密码@主机:5432/数据库名"

}

}

}




}

05 / 四大实战场景

场景一：产品经理自助取数

背景： 某电商平台，运营同事每周都要让DBA出各种数据报告，DBA被查数请求淹没。

传统流程：

运营提需求 → 告知DBA → DBA排期 → 写SQL → 发结果 → 运营反馈不对 → DBA修改 → 2-3天来回

接入PostgreSQL MCP后，运营直接对话AI：

“帮我看下上周（3月24日-3月30日）各品类的GMV和订单量，按GMV倒序排列”

AI自动执行：

SELECT  

c.category_name,

COUNT(o.order_id) AS order_count,

SUM(o.order_amount) AS gmv,

ROUND(SUM(o.order_amount) / SUM(SUM(o.order_amount)) OVER () * 100, 2) AS gmv_pct

FROM orders o

JOIN products p ON o.product_id = p.product_id

JOIN categories c ON p.category_id = c.category_id

WHERE o.created_at BETWEEN '2025-03-24' AND '2025-03-30'

AND o.status NOT IN ('cancelled', 'refunded')

GROUP BY c.category_name




ORDER BY gmv DESC;

返回格式化结果，并主动补充：“家电品类占比最高（34.2%），但环比上周下降了8%，可能需要关注。”

效果： 运营取数时间从2天降至5分钟，DBA每周减少约20个数据请求。

---

场景二：DBA 慢查询诊断

背景： 系统监控告警，某核心接口P99延迟突破500ms，需要快速定位问题SQL。

对话过程：

“最近数据库里有哪些慢查询？帮我找出执行时间最长的5条”

AI调用get_top_queries：

执行时间TOP 5（来自pg_stat_statements）： 
1. 总耗时: 8,234秒
	
调用次数: 12,456
	
平均: 661ms




	


	



SELECT u.*, o.order_count FROM users u

LEFT JOIN (SELECT user_id, COUNT(*) as order_count FROM orders GROUP BY user_id) o

ON u.user_id = o.user_id WHERE u.created_at > $1

2. 总耗时: 4,521秒
	
调用次数: 89,234
	
平均: 51ms




	


	



SELECT * FROM logs WHERE action_type = $1 AND created_at > $2 ORDER BY created_at DESC LIMIT 20




...

“帮我分析第1条查询的执行计划，看看能不能优化”

AI调用explain_query：

问题：子查询对整个orders表做GROUP BY聚合（Seq Scan，成本极高） 

建议：

为 orders(user_id) 添加索引


或改写为窗口函数 / 物化视图

“如果加了这个索引，执行计划会变成什么样？”

AI调用带假设索引的explain_query，模拟添加索引后的效果，显示成本从48,234降至1,203，预计提升40倍。

整个诊断过程：8分钟。传统方式需要熟练DBA手动分析，至少30-60分钟。

---

场景三：数据库上线前例行体检

背景： 每次大促前，DBA需要对数据库做一次全面检查，确保没有潜在风险。

一句话触发：

“帮我对生产库做一次全面健康检查”

AI调用analyze_db_health，几分钟后输出报告：

📊 数据库健康检查报告 — production_db（2025-03-31） 

⚠️ 需要关注（3项）：

未使用索引（6个）

- idx_orders_shipping_address（创建于6个月前，从未使用）

- idx_users_phone_backup（重复索引，已有idx_users_phone覆盖）

建议：评估后DROP，减少写入开销和存储占用

连接数预警

- 当前活跃连接：187/200（93.5%）

- 空闲连接堆积：52个

建议：检查连接池配置，考虑引入PgBouncer

序列风险

- order_id_seq：已使用 82.3%（当前值：823,451,234，最大：2,147,483,647）

建议：在大促前迁移至BIGINT类型

✅ 正常（4项）：

- Buffer命中率：98.7%（健康）

- 复制延迟：12ms（正常）

- Vacuum状态：正常




- 约束完整性：无异常

价值： 把一个需要DBA手动执行十几条诊断SQL的工作，压缩为一次对话。

---

场景四：数据库 Schema 重构辅助

背景： 业务扩张，原有表结构需要调整，开发和DBA需要协同评估影响。

“我需要给orders表加一个freight_cost字段存运费，类型应该用什么？会影响哪些现有查询？”

AI先查询orders表结构和相关表：

SELECT column_name, data_type, is_nullable  

FROM information_schema.columns




WHERE table_name = 'orders';

结合已有字段（order_amount NUMERIC(12,2)）分析，回答：

建议：NUMERIC(10,2)，与order_amount保持一致 

原因：FLOAT/DOUBLE精度损失不适合财务数据

影响评估：

涉及orders表的视图：3个（v_order_summary, v_daily_revenue, v_user_orders）

其中v_order_summary使用SELECT *，需要更新

相关存储过程：2个（需检查是否有INSERT语句需添加字段）
建议ALTER语句：

ALTER TABLE orders ADD COLUMN freight_cost NUMERIC(10,2) DEFAULT 0;




COMMENT ON COLUMN orders.freight_cost IS '订单运费，单位：元';

---

06 / 安全性：不可忽视的红线

接入数据库的AI工具，安全是第一位的。以下几点必须落实。

最小权限原则

永远不要用超级用户或管理员账号接入MCP。专门创建一个只读账号：

-- 创建只读账号 

CREATE USER ai_readonly WITH PASSWORD 'strong_password_here';

-- 授予连接权限

GRANT CONNECT ON DATABASE your_database TO ai_readonly;

-- 授予只读权限（指定Schema）

GRANT USAGE ON SCHEMA public TO ai_readonly;

GRANT SELECT ON ALL TABLES IN SCHEMA public TO ai_readonly;

-- 未来新建表也自动授权

ALTER DEFAULT PRIVILEGES IN SCHEMA public




GRANT SELECT ON TABLES TO ai_readonly;

网络隔离

• AI客户端与数据库之间启用SSL（sslmode=require）

• 配置pg_hba.conf限制只允许特定IP连接

• 生产库不要暴露在公网，使用内网地址

禁用敏感Schema访问

如果数据库中包含敏感表（密码哈希、支付信息、身份证号等），通过权限控制排除在只读账号之外：

-- 撤销对敏感表的访问 

REVOKE SELECT ON TABLE users_credentials FROM ai_readonly;




REVOKE SELECT ON TABLE payment_cards FROM ai_readonly;

审计日志

确保log_min_duration_statement已配置，所有通过MCP发出的查询都应有日志记录：

-- 记录所有执行时间超过100ms的查询 

ALTER SYSTEM SET log_min_duration_statement = '100ms';




SELECT pg_reload_conf();

关于SQL注入风险

2025年的安全研究指出，部分PostgreSQL MCP实现存在通过提示词注入（Prompt Injection）触发SQL执行的风险。选用成熟方案（如Postgres MCP Pro），并保持在受限只读模式下运行，是当前最稳妥的做法。

---

07 / 对 DBA 意味着什么？

PostgreSQL MCP不是来"替代"DBA的，而是改变了DBA的工作方式。

减少的工作：

• 重复性的数据查询和报表需求（转移给非技术用户自助）

• 初级的慢查询排查（AI做初筛，DBA做决策）

• 健康检查的手动执行

增加的价值：

• DBA从"查数工具"变为"数据库架构师"——更多时间投入容量规划、稳定性保障、架构优化

• AI辅助使DBA诊断复杂问题时效率提升，但最终的判断和执行仍需人工

• 对于初级DBA，AI可以成为很好的学习辅助——通过观察AI的SQL写法和分析思路快速提升

一个现实判断：

AI在PostgreSQL运维中的角色，目前最适合定位为"一个随时可以问的高级实习生"——它知道的SQL语法比你多，能快速定位基础问题，但复杂的生产决策（是否要在凌晨做大表DDL，主从切换时机的判断，复杂锁竞争的分析）仍然需要有经验的DBA来主导。

---

08 / 工具选择建议

|
场景
|
推荐方案
|
理由
|
| — | — | — |
|
个人开发/快速体验
|
pgmcp
|
轻量易用，自然语言体验好
|
|
DBA日常运维
|
Postgres MCP Pro
|
功能完整，健康检查+索引调优俱全
|
|
团队协作/业务取数
|
DBHub 或 MCP Toolbox
|
多用户场景，多数据库支持
|
|
Supabase项目
|
Supabase MCP Server
|
平台深度集成
|
|
生产环境
|
任意方案 + restricted模式 + 只读账号
|
安全第一
|

---

写在最后

数据库一直是企业最核心、门槛最高的基础设施之一。它守着所有业务数据，但长期以来只对会写SQL的人开放。

PostgreSQL MCP正在打破这个局面——不是让数据库变得随意，而是让访问它变得更聪明。

DBA的价值不在于垄断SQL能力，而在于对数据库的深度理解和判断力。这个，AI暂时还替代不了。

但那些重复的、机械的取数工作，让AI去做就够了。

---

本文涉及主要工具：

• Postgres MCP Pro：https://github.com/crystaldba/postgres-mcp
• pgmcp：https://github.com/subnetmarco/pgmcp
• DBHub：https://dbhub.ai

---

欢迎大家添加我的个人微信，免费领取福利。

我也会定期分享一些最好用的AI工具、AI技巧、以及各类实操心法,努力去帮助更多的人