把数据库排障留在编辑器里：VS Code 连 PostgreSQL 能做什么、看不到什么

如果你在 VS Code 里写应用，突然需要确认一张表的字段、弄清两张表怎么关联，或者想知道一条查询为什么慢，通常的做法是切到另一个数据库客户端，查完再切回来。微软在 2026 年 10 月 26 日的开发者博客里介绍了 VS Code 的 PostgreSQL 扩展，主张把这部分工作留在编辑器内完成（来源：PostgreSQL Like A Pro: Build, query, and troubleshoot without leaving VS Code）。

简短的回答是：它能覆盖“看结构、写查询、初步判断性能问题”这一段，不能覆盖“确认生产负载全貌、追溯历史变化、验证变更后果”这一段。前者是编辑器内的便利，后者仍然需要指标、日志和可回滚的执行流程。下面按“能做什么”和“看不到什么”分开说，并给出一个可以照着走的核对顺序。

编辑器里能完成的事#

连接与对象浏览

按博客的描述，安装微软的 PostgreSQL 扩展后，从活动栏的 PostgreSQL 图标添加连接，可以连本地或云上的数据库，并把连接配置保存下来复用。对 Azure 上的数据库，走 Azure 连接路径时可以用 Microsoft Entra ID 登录，再选择订阅、服务器和数据库。

连上之后展开服务器、数据库和 schema，可以浏览表、视图、函数、序列和扩展。博客给的建议很务实：先挑一张应用实际用到的表，不必先理解整个库。这一步的价值在于降低“我要先搞懂全部 schema”的心理门槛，而不是提供了什么自动化分析。

写 SQL：补全只是起点，核对才是关键

查询编辑器提供 IntelliSense，覆盖 SQL 语法、表名与列名、连接（join）表达式。这解决的是拼写和记忆问题，不解决语义问题——列名对了，过滤条件仍可能写错。

博客举的例子是“找出某个季度贡献收入最多的客户”，需要连接客户与支付数据、加日期过滤、分组排序。文中提到一种可考虑的改写方向：先把支付数据聚合再连接。注意原文的措辞是“一种可以调查的改写”，不是放之四海皆准的规则。它还明确要求：生成的 SQL 要先审查再运行，并把改写前后的结果做对比。更快但答错问题的查询没有价值，这句话值得抄进排障笔记。

读一个不是自己建的库

接手项目时的典型问题是：数据在哪张表？它和其余部分怎么连？博客建议先在 Object Explorer 里宽泛地看 schema 命名、命名模式和与功能相关的表或视图，再用 schema 可视化追踪对象之间的连接关系。

在 Copilot Chat 里带上数据库上下文后，可以问更聚焦的问题，例如“哪些表包含演员和影片数据”“它们怎么关联”“租赁状态存在哪里”。但原文同时提醒：把回答当作起点，而不是已验证的地图——回到对象树里核对对象，在可视化里检查关系，再跑一条小的只读查询确认数据路径。这个“问一句、验一次、再问下一句”的节奏，比一次性让模型画出整库结构可靠得多。

性能问题：把现象串成证据链

连接掉线、延迟上升说明有问题，但原因通常要靠日志、指标和时间线拼出来。博客提出的顺序是：在动手之前先找一条有用的证据链——什么变了、什么时候变的、涉及哪个负载、为什么某个动作可能有帮助。

它给的例子是：对大事务表上反复出现的客户历史查询，可能引出一条复合索引建议。但下一步不是直接建索引，而是先看支撑指标、预期结果和回滚方案。文中提到的 Database Agent 把这些片段汇总在 VS Code 中的 Azure PostgreSQL 体验里。需要标注的是：博客明确说明，配套视频把 Database Agent 作为“即将推出”的体验介绍，操作需手动应用，自动化修复属于未来能力；当前可用性与 Azure 侧要求应以官方文档为准（待核实）。

编辑器看不到的部分#

以下边界部分来自材料中的提醒，部分是据扩展定位做出的推断，已分别标注。

• 单连接视角，不等于全局负载。你在编辑器里看到的是自己这条会话里的查询与计划。同时段其他会话造成的锁等待、连接池耗尽、I/O 争用，通常要在数据库侧的活动会话视图或监控里看（推断）。
• 没有长期趋势。扩展是交互式工具，不承担指标留存。要回答“上周三下午为什么慢”，需要外部的时间序列数据或日志（推断）。
• AI 的回答没有经过核验。这是材料里的明确态度：Copilot 在数据库上下文中的回答是起点，不是验证过的映射；生成的 SQL 要审查，改写要对比结果。
• 变更的执行与回滚不在它的保证范围内。博客反复强调先看支撑指标、预期结果与回滚指引，说明决策责任仍在人这边；自动化修复在材料里只是未来能力。
• 版本、环境与可用性差异。扩展对不同 PostgreSQL 版本、不同云环境的功能覆盖，本次材料未提供细节，需查官方文档（待核实）。

一个可以照着走的核对顺序#

1. 定问题。先写清你要回答的是“数据在哪”还是“为什么慢”，两者的验证方式不同。
2. 看结构。在 Object Explorer 里定位相关表和视图，用 schema 可视化确认连接路径。
3. 问一句，验一次。向 Copilot 提一个聚焦问题，然后回到对象树和只读查询里确认，再问下一句。
4. 写只读查询。检查表、连接和过滤条件，跑通后确认结果符合需求，再考虑性能。
5. 看计划，不只看速度。对比原始与改写版本的执行计划和结果；速度提升不能替代正确性。
6. 要改就先写清三件事。为什么这个改动应该有用、你打算怎么检查结果、如果没用怎么办。

示例：一条只读查询与它的执行计划#

下面两段 SQL 是演示用示例，未在本环境执行，表名与字段名均为占位，请替换为你的实际对象。

-- 占位示例：未执行
SELECT c.id, c.name, SUM(p.amount) AS revenue
FROM customer AS c
JOIN payment AS p ON p.customer_id = c.id
WHERE p.paid_at >= DATE '2026-07-01'
  AND p.paid_at <  DATE '2026-10-01'
GROUP BY c.id, c.name
ORDER BY revenue DESC
LIMIT 20;

-- 占位示例：未执行
EXPLAIN (ANALYZE, BUFFERS)
SELECT ...;  -- 粘贴上面的查询

说明两点。第一，EXPLAIN ANALYZE 会真正执行语句，只应对只读查询使用；对写语句使用会改动数据，这是 PostgreSQL 的通用行为，不属于本次材料的结论。第二，计划里的估算行数与实际行数差距、以及 BUFFERS 反映的读写块数，是判断索引是否被用上的线索之一；具体阈值取决于你的数据分布，没有通用数字可套。

什么时候应该切出去#

如果问题涉及生产环境的并发行为、跨多个时间点的对比、或者需要改动 schema 与索引，编辑器内的便利就不够了。此时更稳的做法是：在扩展里把查询和计划看明白，把假设写下来，然后到数据库侧的监控与变更流程里验证。博客的落点其实也是这个意思——先把问题问对、把证据凑齐，再决定要不要动手。

想试的话，材料给出的入口是 aka.ms/pg-pro-vs-code-repo（由来源提供，本环境未访问核实其当前内容）。起步动作可以很小：保存一个连接配置，找到一张应用在用的表，看清它的结构与关系，再写一条只读查询跑通。