使用一致参数命名和静态SQL结构防止计划缓存污染，避免动态拼接参数名或SQL语句，推荐语义化参数如@CustomerId，复用DbCommand并监控执行计划缓存。
在C#中进行数据库查询时，参数化是防止SQL注入和提升执行效率的关键手段。但若使用不当，尤其是动态生成参数名称或数量，容易导致计划缓存污染——即数据库为相似查询生成大量不同的执行计划，浪费内存并降低性能。
使用一致的参数命名
每次执行查询时，应确保参数名称保持一致。避免通过字符串拼接动态生成参数名（如 @param1、@param2 随行号变化），这会让数据库认为是不同语句，从而产生多个执行计划。
正确做法是根据字段语义命名参数：
- 推荐：@CustomerId、@OrderDate
- 避免：@p1、@p2 或 @param_123
避免过度动态SQL拼接
即使使用参数化，若SQL文本本身频繁变化（例如因条件增减而拼接不同WHERE子句），也会导致缓存碎片化。
优化建议：
- 使用静态或模板化SQL语句，配合NULL条件过滤
- 利用ORM（如Entity Framework）生成标准化SQL
- 对复杂动态查询，可考虑存储过程封装逻辑
示例：统一使用同一结构SQL，通过参数是否为NULL控制条件生效：
SELECT * FROM Orders WHERE (@CustomerId IS NULL OR CustomerId = @CustomerId) AND (@Status IS NULL OR Status = @Status)
合理复用DbCommand与参数集合
在高频调用场景下，重复创建命令对象和参数会增加开销。可复用DbCommand实例（注意线程安全），并清空后重用参数集合。
关键点：
- 设置参数值前先清除旧值或明确赋值
- 避免重复添加同名参数
- 使用AddWithValue时注意类型推断问题，最好显式指定类型
监控与识别缓存污染
可通过数据库层面监控执行计划缓存情况。以SQL Server为例：
SELECT
text,
usecounts,
plan_handle
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle)
ORDER BY usecounts ASC若发现大量相似SQL仅参数名或值不同且usecounts = 1，说明存在缓存污染。
基本上就这些。核心是保持SQL文本和参数结构稳定，让数据库能有效复用执行计划。不复杂但容易忽略细节。
