Dapper的缓存机制不是单一的“结果缓存”，而是分层、轻量、内存驻留的多级缓存体系，核心目标是消除重复解析和映射开销，而非替代Redis这类分布式缓存。它不缓存查询结果数据本身（比如100条User记录），而是缓存“怎么执行”和“怎么转换”的逻辑。
查询执行计划缓存（一级缓存）
每次执行SQL时，Dapper会生成一个唯一的 Identity 键，包含：SQL语句哈希值、参数类型、连接字符串标识、结果类型。这个键用于查
ConcurrentDictionary<identity cacheinfo></identity>—— 全局静态线程安全字典。
命中后直接复用已编译的执行逻辑，包括：
参数绑定器（ParamReader） 结果反序列化器（
DeserializerState） 列结构解析状态（如字段名、类型、顺序）
避免了每次查询都重新编译命令、反射获取属性、遍历DataReader列等操作。
类型映射反序列化器缓存（二级缓存）
这部分由 TypeDeserializerCache 管理，采用双重键控设计：
外层按Type（如
Product）索引，用静态
Hashtable byType存储 内层按
DeserializerKey（含列名数组、列类型、起始偏移、是否允许null等）区分不同查询上下文
例如：
SELECT Id, Name FROM Products和
SELECT Name, Price FROM Products即使映射到同一类型，也会生成两个不同的反序列化函数，互不干扰。
缓存键是怎么算出来的？
关键方法是
GetColumnHash，它对DataReader的列信息做加权哈希： 遍历每一列，把
GetName(i)和
GetFieldType(i)的哈希值参与运算 引入
startBound和
length支持跳过前几列或只取部分列（适配匿名对象、多结果集） 使用 unchecked int 运算保证哈希一致性，不抛溢出异常
这种设计让缓存键真正反映“数据结构特征”，而不是简单拼接SQL字符串。
缓存怎么清理和监控？
Dapper默认不主动过期缓存，但有被动淘汰策略：
每新增1000个缓存项，检查命中次数低于1的低效项并清除 提供手动清理接口：SqlMapper.PurgeQueryCacheByType(typeof(T))或
SqlMapper.PurgeQueryCache()可监控：
SqlMapper.GetCachedSQLCount()、
SqlMapper.GetCachedSQL(ignoreHitCountAbove: 5)查低频查询
注意：
CommandFlags.NoCache可临时绕过整个缓存链，适合动态SQL或实时性极高的场景。
基本上就这些。它不复杂，但容易忽略——缓存生效的前提是SQL文本、参数类型、目标类型、连接字符串（或至少Provider）保持稳定。只要其中一项变了，就是新缓存键。
