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）重用执行计划，避免每次解析编译。

匿名对象 new { Id = 123 } 和 DynamicParameters 均自动转为安全参数，杜绝拼接风险
列表参数（WHERE Id IN @Ids）支持智能填充（PadListExpansions）和字符串拆分（InListStringSplitCount），防止因参数长度不同导致执行计划爆炸式增长
内置 _queryCache 字典缓存已编译的命令定义（CommandDefinition），减少 ADO.NET 层重复构建

连接与结果流控由你主导

Dapper 不封装连接池，但完全兼容 ADO.NET 连接池机制；它也不强制缓冲结果，而是把选择权交给开发者：

用 using(var conn = new SqlConnection(...)) 确保连接及时归还池中，避免耗尽
大数据集可设 buffered: false，让 Query() 返回惰性枚举器，边读边处理，内存零堆积
支持 CommandFlags.NoCache 绕过 Dapper 自身缓存，适合动态 SQL 场景；也支持 Pipelined 实现异步管道化查询

基本上就这些。它不试图做全能框架，只把“执行 SQL → 映射对象”这件事做到极致轻、极致稳、极致快。

# 大数据 # app # c# # 延迟加载 # 内存占用 # .net # 为什么 # red # sql # 封装 # 字符串 # int # 堆 # using # var # 类型转换 # 对象 # 异步 # postgresql # 数据库 # 都是 # 没做 # 复用 # 这一 # 连接池 # 首次 # 这段 # 这件事 # 不做 # 不走