当我首次构建.NET API时，曾为架构的简洁优雅而自豪。但这种自豪感并未持续太久。真实用户开始访问后，抱怨接踵而至："API响应太慢了"。
起初我并未在意——毕竟接口功能正常、代码可测试，开发环境一切良好。直到我做了每个开发者都畏惧的事：运行负载测试。
残酷的现实给了我当头一棒：在中等流量下API就已不堪重负。单个本应50毫秒内完成的接口，实际耗时竟达200毫秒。当请求量达到数千次时，这个性能瓶颈已不容忽视。
本文将分享我如何定位问题根源，发现EF Core编译查询，最终实现40%性能提升的全过程。包含心路历程、基准测试、踩坑经验，以及如何在你的API中复现这种优化。
为什么API性能比你想象的更重要
在深入技术细节前，先明确背景：
如果构建的是内部仪表盘API，你可能会觉得"200毫秒无伤大雅"。但在生产系统中——特别是每小时处理数万请求的场景——每毫秒都至关重要。
-
• 更快的API意味着更满意的用户 -
• 更快的API意味着更低的基础设施成本（用更少服务器处理相同负载） -
• 更快的API意味着在引入缓存、分片或升级硬件前拥有更多扩展空间
这些都是我用惨痛教训换来的经验。
瓶颈所在：Entity Framework Core
作为EF Core多年使用者，我一直欣赏其优雅强大，能让我专注于业务逻辑而非SQL模板代码。
但如同任何抽象层，它也存在代价。EF Core需要解析LINQ表达式、转换为SQL、缓存查询计划并执行。大多数时候这种开销不易察觉，但在高负载下？积少成多的影响将十分显著。
以下是我当时存在问题的API端点简化版：
[HttpGet("{id}")]
public async Task<IActionResult> GetCustomer(int id)
{
var customer = await _dbContext.Customers
.Where(c => c.Id == id)
.FirstOrDefaultAsync();
if (customer == null)
return NotFound();
return Ok(customer);
}
看起来人畜无害对吗？但在底层，EF Core每次都在重复编译查询表达式树。这意味着本可一次性完成的准备工作，却在持续消耗额外的CPU周期。
顿悟时刻：发现EF Core编译查询
在研读EF Core文档时，我偶然发现了"编译查询"功能。
简而言之：你可以预先编译LINQ-to-SQL转换逻辑，生成可复用的委托，避免EF Core每次调用时重复编译。
这正是我需要的"灵光时刻"。如果EF Core确实在执行重复的高成本工作，编译查询或许能显著降低开销。
剧透预警：它确实做到了。
使用编译查询重写端点
以下是使用编译查询重构后的端点：
private static readonly Func<MyDbContext, int, Task<Customer?>> _compiledGetCustomer =
EF.CompileAsyncQuery((MyDbContext context, int id) =>
context.Customers.FirstOrDefault(c => c.Id == id));
[HttpGet("{id}")]
public async Task<IActionResult> GetCustomer(int id)
{
var customer = await _compiledGetCustomer(_dbContext, id);
if (customer == null)
return NotFound();
return Ok(customer);
}
注意关键差异：
-
• 不再让EF Core每次解析编译查询，而是在类级别一次性定义 -
• 每个API调用现在只需执行预编译的委托
这意味着：
-
• 更低的CPU开销 -
• 更少的内存分配 -
• 高负载下更好的吞吐量
基准测试实践
我不愿仅凭直觉下结论——需要数据支撑。
于是使用BenchmarkDotNet搭建了基准测试，以下是简化版本：
[MemoryDiagnoser]
publicclassEfCoreBenchmark
{
privatereadonly MyDbContext _dbContext;
public EfCoreBenchmark()
{
_dbContext = new MyDbContext();
}
[Benchmark]
publicasync Task<Customer?> NormalQuery()
{
returnawait _dbContext.Customers
.FirstOrDefaultAsync(c => c.Id == 1);
}
privatestaticreadonly Func<MyDbContext, int, Task<Customer?>> _compiledQuery =
EF.CompileAsyncQuery((MyDbContext context, int id) =>
context.Customers.FirstOrDefault(c => c.Id == id));
[Benchmark]
publicasync Task<Customer?> CompiledQuery()
{
returnawait _compiledQuery(_dbContext, 1);
}
}
我的机器测试结果如下（具体数值可能变化，但趋势保持不变）：
（此处原图说明文字已保留）
按回车或点击查看完整图片
来源：作者
性能提升约40%，内存分配减少近半。在轻量使用场景下可能不明显，但在大规模应用中堪称颠覆性改变。
隐形成本与权衡
当然，没有免费的午餐。编译查询也存在注意事项：
-
• 复杂性：无法轻松添加 .Include()链或动态过滤器，查询必须预先明确定义 -
• 可维护性：模型变更时需要重新审视编译查询 -
• 适用场景：切忌过度使用。编译查询最适合"热路径"——每秒调用数千次的查询，低频查询的复杂度得不偿失
经验总结
本次探索带来的核心启示：
-
• 测量优先：避免盲目优化，先分析、基准测试，再修复瓶颈 -
• 目标聚焦：编译查询适用于高频端点，非一次性查询 -
• 保持简洁：在性能收益与代码可维护性间寻求平衡 -
• 理性看待EF Core：理解内部机制才能发挥最佳性能
分步指南：如何实践应用
若想在项目中尝试EF Core编译查询，请遵循以下路径：
-
1. 识别慢速端点：使用Application Insights、日志记录或负载测试 -
2. 检查EF Core开销：分析是否存在查询重复编译 -
3. 引入编译查询：
private static readonly Func<MyDbContext, int, Task<Customer?>> _compiledGetCustomer =
EF.CompileAsyncQuery((MyDbContext context, int id) =>
context.Customers.FirstOrDefault(c => c.Id == id));
-
4. 替换高频查询：从调用最频繁的端点开始 -
5. 前后基准测试：验证改进效果 -
6. 记录权衡决策：确保后续开发者了解使用编译查询的原因
超越编译查询：其他API加速技巧
除编译查询外，我还结合使用了以下技术：
-
• 只读查询使用 AsNoTracking() -
• 尽可能批量查询替代循环查询 -
• 对真正热点的数据添加缓存 -
• 连接池化与高效DbContext使用
编译查询并非银弹，但与这些技术结合使用，将使你的API性能突飞猛进。
开始这段旅程时，我未曾料到"预编译查询"这般简单的优化能产生如此显著的影响。但在真实系统中，微小改进会积少成多——编译查询几乎零成本地带来了40%的性能提升。
如果你正在使用EF Core构建.NET API，我强烈建议尝试编译查询。从小处着手，谨慎测试，找到最适合的应用场景。
性能优化永无止境——但有时，最简单的优化手段反而能带来最丰厚的回报。
现在就去运行那些基准测试吧——你会惊讶地发现，原来性能提升的机会近在眼前。