Dapper性能为什么这么快 Dapper性能原理深度解析

Dapper快的核心在于“没做什么”：无状态设计、零对象跟踪、静态方法调用、编译级映射缓存、参数化查询优化、连接与流控由开发者主导，专注SQL执行与对象映射。

Dapper快，核心不是“它做了什么”，而是“它没做什么”——它绕开了传统ORM里大量与业务无关的抽象、状态跟踪和运行时开销，把数据库访问压缩到最接近原生 ADO.NET 的效率层级。

无状态设计，零对象跟踪

Dapper不维护实体生命周期，不记录对象变更，不做延迟加载或导航属性解析。每次查询都是干净的“请求-响应”，没有 EF 那种 ChangeTracker、DbContext 状态管理带来的内存占用和同步成本。所有映射都是一次性、无副作用的转换。

• 没有上下文实例化开销，全是静态方法调用（如 SqlMapper.Query()）
• 不生成代理类，不拦截属性访问，避免虚方法调用和反射 setter
• 连接打开、执行、关闭全程由开发者控制，Dapper 只负责“读数据+转对象”这一件事

编译级映射缓存，告别重复反射

首次执行某条 SQL 查询时，Dapper 会分析结果集列名、类型和目标类结构，动态生成一段轻量 C# 映射代码（类似手动写的 reader.GetInt32(0), reader.GetString(1)），并缓存进 ConcurrentDictionary。后续同结构查询直接复用这段代码，跳过全部反射逻辑。

• 缓存键包含 SQL 文本哈希 + 参数类型 + 返回类型，精准命中
• 映射过程不走 Activator.CreateInstance 或 PropertyInfo.SetValue，性能接近手写 DataReader
• 类型转换逻辑内联处理（如 int? → int），避免装箱/拆箱和异常兜底

查询计划复用与参数化原生支持

Dapper 默认启用参数化查询，且深度适配数据库执行计划缓存机制。SQL Server、PostgreSQL 等都能对相同参数化模板（如 WHERE Id = @Id）重用执行计划，避免每次解析编译。

标签： 大数据 app c# 延迟加载 内存占用 .net 为什么 red