.NET 性能风暴：如何将接口耗时从 2000ms 优化到 15ms（含 PostgreSQL 实战调优）

在微服务的实施过程中，监控链路透明度是极其关键的一环。之前我分享过怎么一套跑通 OpenTelemetry，当系统终于拥有了可观测性后，一个更刺眼的问题暴露了：在监控大屏上，请求耗时的大头居然全在数据库响应上，部分复杂查询耗时甚至超过了 2 秒！

本文将复盘我如何在 .NET + PostgreSQL 架构下，通过监控追踪快速定位问题，并仅通过三步操作，将那些令人抓狂的慢接口优化到毫秒级别。

一、排查第一步：必须看见"慢"在哪（pg_stat_statements）

如果你的 PostgreSQL 还在凭感觉建索引，请立即开启 pg_stat_statements 插件。它是性能调优的地基。

如何开启 ：修改 postgresql.conf 文件：

ini 复制代码

shared_preload_libraries = 'pg_stat_statements'
pg_stat_statements.track = all
pg_stat_statements.max = 10000

并在数据库中执行：CREATE EXTENSION pg_stat_statements;

打通了从 OTel 的 Trace 到 PG 耗时统计的闭环后，我立刻锁定了几个"性能刺客"。

二、实战排雷：三个血淋淋的性能痛点

痛点 1：夺命 N+1 问题 (ORM 的通病)

灾难现场 ：有一个获取用户列表并附带用户附加标签信息的服务，请求耗时 1.5 秒。通过追踪系统看到，短短一个请求居然抛出了 100 多条离散的 SELECT 语句！这典型的 N+1 问题，是因为在循环体内触发了未即时加载的导航属性查询。

解毒方案 ：无论是 EF Core 还是 SqlSugar，都必须在一次查询中利用 Join 或 IN () 的形式拉取关联数据。在 SqlSugar 中，应当使用 Includes 在初次查询时合并加载：

csharp 复制代码

// 优化后：利用导航属性一次性带出
var userList = await _db.Queryable<User>()
    .Includes(u => u.Tags) 
    .Where(u => u.Status == 1)
    .ToListAsync();

优化结果：直接从 1500ms 骤降到 80ms。

痛点 2：失效的复合索引与全表扫描

灾难现场 ：随着历史日志数据量突破百万大关，一个只带有时间范围和排序的日志分页接口，耗时涨到了惊人的 2.2 秒。通过 EXPLAIN ANALYZE 解析发现，虽然操作者 ID 字段有单列索引，但优化器判定回表成本太高，依然执行了 Seq Scan (全表扫描)。

原始缺陷查询：

sql 复制代码

SELECT * FROM action_logs 
WHERE operator_id = 9527 AND action_time >= '2026-01-01' 
ORDER BY create_time DESC 
LIMIT 20 OFFSET 0;

解毒方案：建立正确的复合索引 为了支持高频的范围过滤加排序查询组合，必须建立对应的复合倒排索引，并利用索引直接满足排序：

sql 复制代码

CREATE INDEX idx_logs_operator_time_created 
ON action_logs (operator_id, action_time, create_time DESC);

优化结果 ：查询计划转向 Index Scan，耗时从 2200ms 重归毫秒级（约 15ms）。

痛点 3：无节制 JSONB 带来的过滤灾难

灾难现场：作为经常需要无 Schema 扩展的数据，PG 的 JSONB 很好用。但我却把部分需要高频过滤的属性丢在里面（例如根据扩展配置里的某个开关寻找用户）。无索引的情况下去根据 JSON 节点值过滤百万表，就是自找苦吃。

解毒方案 ：对于只查询某个特定 JSONB 节点的场景，表达式索引（Expression Index）是最轻量、最锋利的刀：

sql 复制代码

CREATE INDEX idx_users_is_active 
ON users ((extra_config ->> 'IsActive'));

此时你查询 WHERE extra_config ->> 'IsActive' = 'true'，就能完美吃到索引红利。

三、架构级保底：被遗忘的连接池风暴

除了具体的慢 SQL，我还遇到了在高并发测试下的 FATAL: sorry, too many clients already 错误。

不同于 MySQL，PostgreSQL 每个连接都是一个物理进程。单纯依赖 .NET 自带的内置连接池应对分布式下横向扩展的多服务节点，是极度危险的。

最终方案：引入 PgBouncer 不再让应用直连 PG，而是部署一层 PgBouncer，采用 transaction (事务池化) 模式。应用与 PgBouncer 建立成百上千个轻量级连接，PgBouncer 在后端始终只保持稳定数量的数据库真实连接进程。资源耗尽的炸弹被彻底拆除。

结语

不要迷信纯代码层面的魔法优化。性能优化永远是系统工程：从可观测性找到问题点 -> 看懂执行计划 -> 对症下药修补索引 / 优化 ORM -> 把控底层的网关和连接层边界。

下一篇，我将分享如何把这套体系平滑向更进阶的云原生底座迁移。希望我的实战经验能够对陷于"不知哪慢"泥潭中的你有所启发！

欢迎关注我的主页交流：dotnetjiangbo (西安的老陕同行，欢迎后台踢我！)