PostgreSQL 性能工作应该在你写代码的地方进行

Emiliano Montesdeoca — Mon, 20 Jul 2026 00:00:00 +0000

我同意这个 Azure 更新的核心论点：性能工作失败更少是因为缺少工具，更多是因为上下文碎片化。大多数团队已经有监控、查询编辑器和运维仪表盘。他们缺乏的是从信号到行动的连续性。

VS Code 中的 PostgreSQL 扩展方向之所以重要，是因为它缩短了那条路径。当服务器指标、查询计划和顾问建议出现在开发者已经编辑 SQL 的同一个地方时，团队从诊断到修复的速度就会加快。这听起来很明显，但在真实组织中这是一个结构性转变。上下文切换正是所有权丢失的地方。

以下是对工程负责人的实用部分。如果你想要可衡量的提升，不要把这几项功能作为可选的锦上添花来引入。让它们成为你审查工作流的一部分：

文章还将 Azure HorizonDB 定位为前瞻选择，同时让 Azure Database for PostgreSQL 保持为当前的生产默认。这正是正确的框架。团队在过早将预览期技术兴奋转化为运维承诺时会遇到麻烦。先稳定，再有选择地实验。

我强烈的观点：性能文化在成为云问题之前首先是编辑器问题。如果调优只在火线和作战室中进行，你做的不是性能工程，而是性能事件响应。VS Code 集成故事帮助团队左移，在那里修复成本更低。

有一个注意事项。集成的建议可能会导致过度自信，如果团队停止基于工作负载行为验证假设。AI 辅助调优和顾问提示是加速器，而非基准纪律的替代品。你仍然需要基线、可重复的负载测试和回归门控。

如果你的组织在 Azure 上大规模运行 PostgreSQL，现在正确的做法是标准化这个集成工作流，然后检测从问题检测到缓解的周期时间。性能红利是真实的，但前提是你把它运维化。否则，它只是另一个功能演示。

核心观点： 不要购买更多的可观测性。缩短从洞察到变更的距离。

Database-Performance | The .NET Blog