使用LINQ查询Azure DB分页数据耗时过长，求低成本优化方案

我来分享几个在Azure SQL DB上优化LINQ分页查询的实用方案，都是我实际项目里验证过的，应该能帮你把那2分钟的耗时大幅降下来：

1. 先把索引这件事做对 #

这是最容易见效的一步，很多慢查询都是因为缺少合适的索引：

• 针对你的两个筛选条件创建复合索引，把筛选频率更高的列放在索引前面。比如你的查询是Where(x => x.CategoryId == 123 && x.IsActive == true)，就创建包含这两列的复合索引，同时如果分页需要排序，把排序列也加入索引（比如CreateTime）。
• 用Azure Portal的查询性能分析器或者SQL Server Management Studio查看查询执行计划，要是看到表扫描或索引扫描，说明索引没覆盖到查询逻辑，得调整索引结构。
• 注意：如果用了Skip().Take()，排序字段一定要在索引里，不然数据库会先全表排序再分页，这对12万条数据来说简直是灾难。

2. 别加载不需要的数据 #

• 不要用Select(x => x)加载整个实体，只选你需要的列，比如Select(x => new { x.Id, x.Name, x.CreateTime })。这样既能减少数据传输量，还能让索引覆盖查询（如果索引包含这些列），避免回表查询的开销。
• 关闭EF的延迟加载（或者用AsNoTracking()），防止不小心触发导航属性的额外查询，拖慢整体速度。

3. 换掉低效的Skip().Take()，用键集分页 #

传统的Skip().Take()在数据量大时，越往后的页越慢——因为数据库要跳过前面所有行才能取到目标数据。改用键集分页（Keyset Pagination）能彻底解决这个问题：

// 假设上一页最后一条记录的CreateTime是lastCreateTime，Id是lastId
var nextPage = dbContext.YourTable
  .Where(x => x.CategoryId == 123 && x.IsActive == true)
  // 用唯一排序键定位下一页起始位置
  .Where(x => x.CreateTime > lastCreateTime || (x.CreateTime == lastCreateTime && x.Id > lastId))
  .OrderBy(x => x.CreateTime).ThenBy(x => x.Id)
  .Take(10)
  .ToList();

这种方式利用索引直接定位到起始位置，完全避免了Skip的开销，性能提升非常明显，尤其是页数较多的时候。

4. 让EF生成更高效的SQL #

有时候LINQ写法会让EF生成冗余SQL，比如：

• 避免在Where里调用自定义方法，尽量用EF能直接转换成SQL的表达式（比如用EF.Functions.Like替代自定义的模糊匹配逻辑）。
• 确保所有筛选、排序逻辑都在数据库端执行，不要在Where之前调用ToList()把数据加载到内存再处理。

5. 检查Azure DB的资源配置 #

• 看看你的Azure SQL DB服务层级是不是够，比如Basic层的CPU、IO资源有限，如果经常出现CPU使用率过高、IO等待时间长的情况，考虑升级到Standard或Premium层。
• 开启Azure DB的查询存储（Query Store），它会自动识别慢查询，还能给出创建索引、重写查询的具体建议。

6. 缓存高频查询结果 #

如果你的筛选条件固定、数据更新不频繁，可以把分页结果缓存起来（比如用Redis或MemoryCache），第一次查询后，后续请求直接从缓存取，不用每次都碰数据库。

这些方案里，索引优化和键集分页通常能最快看到效果，你可以先从这两点入手排查。

内容的提问来源于stack exchange，提问作者Pranav Mishra