在 VS Code 里完成 PostgreSQL 建表、查询与排障：边界与替代方案

如果你只是想回答“能不能不离开 VS Code 就把 PostgreSQL 的表建了、查询跑了、慢查询看了”，答案是：日常开发中最常见的几件事可以，但每件事都有它管不到的部分。微软开发者博客在 2026 年 10 月 26 日的一篇文章里，把 VS Code 的 PostgreSQL 扩展归纳为四条路径：连接并浏览对象、写可解释的 SQL、理解别人建的库、把性能问题转成可复核的决策（来源：Microsoft for Developers）。本文按这四条路径拆开讲清楚边界，再说明哪些环节需要换工具。

一、连接与浏览：扩展最扎实的部分#

按材料描述，安装微软的 PostgreSQL 扩展后，在活动栏点击 PostgreSQL 图标即可添加连接；连接配置可以保存复用。面向 Azure 上的数据库时，有一条 Azure 连接路径，用 Microsoft Entra ID 登录后选择订阅、服务器和数据库。连接成功后，展开服务器、数据库和 schema，可以浏览表、视图、函数、序列和扩展。

这一步的价值在于降低“上下文切换成本”——你正在读代码，顺手就能确认某个字段到底叫什么、某张表在哪个 schema 下。材料给的建议很克制：先从一个你应用真正用到的表开始，不需要理解整个库。

边界也在这里：对象树展示的是结构，不是数据分布、访问频率或历史变更。想知道某张表最近写入量、某列的选择性，扩展本身不提供，需要查询统计视图或依赖监控系统（这部分本次材料未涉及）。

二、建表：入口在编辑器，责任不在编辑器#

需要说清楚一点：这篇材料的主线是连接、查询、理解 schema 与性能排查，并没有给出建表的具体流程。从扩展提供的查询编辑器可以执行 SQL 这一点推断，建表在操作层面就是执行 DDL；但表怎么设计，扩展不参与决策。

下面是一个占位示例，未在任何真实数据库执行，仅用于说明结构，不代表推荐的表设计：

-- 占位示例，未执行
CREATE SCHEMA IF NOT EXISTS app;

CREATE TABLE app.customer (
  id          bigint PRIMARY KEY,
  name        text NOT NULL,
  created_at  timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE app.payment (
  id            bigint PRIMARY KEY,
  customer_id   bigint NOT NULL REFERENCES app.customer(id),
  amount_cents  bigint NOT NULL CHECK (amount_cents >= 0),
  paid_at       timestamptz NOT NULL
);

真正需要额外安排的，是编辑器之外的三件事：一是约束与索引策略（主键选什么、外键要不要、哪些列建索引）；二是变更的版本化与回滚，通常交给迁移工具管理；三是多人协作时的 schema 评审。这三件在本次材料中都没有覆盖，属于需要另行补齐的部分。如果你的项目已经有迁移流水线，那么在 VS Code 里手写 DDL 更适合作为探索手段，而不是发布手段。

三、查询：IntelliSense 提效率，Copilot 提线索#

材料提到，查询编辑器的 IntelliSense 覆盖 SQL 语法、表名与列名、join 表达式。这对“写得出、写得对”帮助直接：拼错的列名当场就能发现，不必等到执行报错。

材料举的场景是“找出某个季度贡献营收最多的客户”，需要 join 客户与支付数据、加时间过滤、分组排序。示例查询如下，同样未执行，$1、$2 为参数占位：

-- 占位示例，未执行
SELECT c.id, c.name, SUM(p.amount_cents) AS revenue_cents
FROM app.customer AS c
JOIN app.payment  AS p ON p.customer_id = c.id
WHERE p.paid_at >= $1 AND p.paid_at < $2
GROUP BY c.id, c.name
ORDER BY revenue_cents DESC
LIMIT 20;

材料给出的一个重要提醒是：先把支付数据聚合再 join，是一种可以调查的重写方向，不是通用规则。换句话说，它值得作为对照实验，而不是默认答案。对应的写法大致如下：

-- 占位示例，未执行；仅作对照，不表示更快
WITH agg AS (
  SELECT customer_id, SUM(amount_cents) AS revenue_cents
  FROM app.payment
  WHERE paid_at >= $1 AND paid_at < $2
  GROUP BY customer_id
)
SELECT c.id, c.name, agg.revenue_cents
FROM app.customer AS c
JOIN agg ON agg.customer_id = c.id
ORDER BY agg.revenue_cents DESC
LIMIT 20;

是否更快，取决于数据量、索引、统计信息与执行计划，不能从写法本身推出来。材料强调了两条纪律：执行前审阅生成的 SQL；执行后把原始查询与改写查询的结果也做比对——更快的查询仍然要回答对的问题。

四、读别人的库：把答案当地图草稿#

接手陌生项目时，第一反应通常是“这个功能的数据在哪张表”。材料建议先在对象树里宽泛地找：看 schema 命名、命名规律、与当前功能匹配的表或视图；然后用 schema 可视化追踪相关对象之间的连线。

Copilot Chat 在拿到数据库上下文后，可以回答诸如“哪些表存演员和影片数据”“它们怎么关联”“租赁状态存在哪里”这类聚焦问题。但材料明确要求：把回答当作起点，不是已验证的地图。验证方式也给了——在对象树里核对对象、在可视化里核对关系、跑一条小的只读查询确认数据路径。

这里的边界是权限与安全：材料没有讨论只读账号、数据脱敏或敏感表访问控制。连接生产库做探索前，这些属于需要自行确认的前置条件。

五、排障：先建证据链，再谈改什么#

材料把性能问题拆成一条可复核的链条：什么变了、什么时候变的、涉及哪部分负载、为什么某个动作可能有效。连接掉线、延迟上升是信号，但要定位原因，通常需要收集日志、对比指标、拼出时间线——这些动作在编辑器内可以发起，但数据来源不全在编辑器内。

材料举的例子是：对大事务表反复做客户历史查询，可能引出复合索引的建议。重点不在建议本身，而在下一步：先看支撑该建议的指标、预期结果和回滚方式，再决定是否创建索引。

材料中有一条可用性说明：配套视频把 Database Agent 介绍为“即将推出的体验”，动作由人工手动应用；自动化修复被描述为未来能力，并提示核实当前可用性与 Azure 要求。截至本文写作日期（2026-10-31），其实际状态待核实，不宜按“已能自动处置”来设计流程。

材料给的自检问题值得抄下来：你能解释为什么这个改动会有帮助、打算怎么检验结果、如果没效果怎么办吗？三个问题答不上来，就先别改。

六、边界与替代方案#

把上面几条并起来看，扩展覆盖的是“开发者在编码过程中的数据库动作”，不覆盖“数据库作为生产系统被长期运营”的部分。可以按需求对照：

需要强调：表格右列是类别性的建议，不是选型结论。具体工具的功能边界、版本支持与授权方式，本材料没有提供，也无法据此外推，需按官方文档核实。

七、一个可执行的上手顺序#

1. 保存一份连接配置，挑一个业务用到的表，看清它的字段与关联。
2. 写一条只读查询，先核对表、join 条件与过滤条件，再执行并确认结果符合预期。
3. 遇到慢查询时，先取执行计划，再看是否需要对照重写；两种写法都跑一遍，比对结果行数与聚合值。
4. 如果得到索引或参数调整建议，先写出“为什么有效、怎么验证、无效怎么办”三句话，再决定是否执行。

扩展的定位可以概括为：它让“查一下”这件事变便宜，但不让“改一下”这件事变安全。建表、改索引、调参数这类动作，验证责任仍然在人这边。想进一步了解扩展本身，可以看官方的示例仓库（链接由材料给出，内容未核验）。