yield本身不提速，但配合DbDataReader或IAsyncEnumerable<T>可实现零缓冲流式处理；关键在于全程避免内存堆积，从SQL精简、SequentialAccess、AsNoTracking到流式Excel写入缺一不可。
Yield 本身不提速，但它是实现真正流式处理的必要语法糖；关键在配合 DbDataReader 或 IAsyncEnumerable<T> 避免内存堆积。
为什么 yield return 不能直接加速数据库读取
很多人误以为只要把方法改成 yield return 就能“流式导出”，其实不然。如果底层还是用 DataTable.Load() 或 ToList() 把全部结果塞进内存，yield 只是把已加载完的大集合“假装”成迭代器，毫无意义。
- 真正起作用的是：数据源必须支持逐行拉取（如
DbDataReader），且消费方不缓存整批结果 -
yield的价值是让方法返回IEnumerable<T>或IAsyncEnumerable<T>，从而把“何时读、读多少”的控制权交给调用方 - 若导出逻辑里有
.ToArray()、.Count()、First()等触发立即执行的操作，整个流就提前终结了
用 yield + DbDataReader 实现零缓冲流式读取
这是最贴近“边读边导”的做法，适用于 MySQL、SQL Server、SQLite 等所有支持原生 DbDataReader 的 ADO.NET 提供程序。
- 必须传入打开的
DbCommand，并指定CommandBehavior.SequentialAccess，否则驱动仍会预加载整结果集 - 不能调用
reader.GetOrdinal()或按列名访问——要按顺序读，且只能读一次（不可回退） - 示例核心结构：
public static async IAsyncEnumerable<Order> ReadOrdersAsync(DbCommand cmd)
{
await using var reader = await cmd.ExecuteReaderAsync(CommandBehavior.SequentialAccess);
while (await reader.ReadAsync())
{
yield return new Order
{
Id = reader.GetInt32(0),
Name = reader.GetString(1),
Amount = reader.GetDecimal(2)
};
}
}
- 调用时直接对接 Excel 写入器（如
MiniExcel.SaveAsAsync()），不经过中间集合 - 注意：SQL 查询必须精简字段，避免
SELECT *——多一个nvarchar(max)字段就可能让单行内存翻倍
EF Core 中如何安全使用 AsAsyncEnumerable() 替代 yield
EF Core 6+ 原生支持 AsAsyncEnumerable()，它底层封装了 DbDataReader 流式行为，比手写 yield 更可靠，也更易维护。
- 必须关闭跟踪：
AsNoTracking()，否则每行都会被 EF 缓存并建立变更追踪 - 禁止在查询中调用
Include()多表关联——这会导致笛卡尔积膨胀，失去流式意义 - 不能用
OrderBy().Skip().Take()分页，应改为主键范围查询（如WHERE id > @lastId LIMIT 1000） - 示例：
await foreach (var order in context.Orders
.Where(x => x.CreatedAt >= startDate)
.AsNoTracking()
.AsAsyncEnumerable())
{
await excelWriter.WriteRowAsync(order); // 直接写入，不暂存
}
- 若需映射到 DTO，用
Select()投影而非AsNoTracking().Select(...).AsAsyncEnumerable()——后者仍会走实体构建流程
导出环节最容易被忽略的三个内存爆点
即使读取端完全流式，导出阶段仍可能瞬间吃光内存，尤其在用 EPPlus 时。
-
ExcelPackage默认将整个工作簿保留在内存中；百万行导出前务必启用流式模式：new ExcelPackage(new FileInfo(path), true)（true表示 stream-based） - MiniExcel 是目前唯一默认流式写入的库，
SaveAsAsync()内部直接写入FileStream，无需额外配置 - 千万别在循环里反复调用
worksheet.Cells[row, col].Value = xxx——每次访问都触发内部对象创建；应改用worksheet.Cells["A1:Z1000000"].LoadFromCollection(...)批量加载（但仅限小批量，大集合仍会内存溢出）
真正的流式不是“选个库就行”，而是从 SQL 查询、DataReader 行为、DTO 构建、Excel 写入四个环节全部切断内存缓存链路。任何一个环节偷偷缓存，前面所有优化都归零。
