我来帮你拆解这个棘手的问题——你遇到的情况非常典型：直接在SSMS里跑捕获到的SQL完全正常，但用Dapper带事务执行就报错，移除事务或者替换掉之前的QueryMultiple操作后问题就消失了，这说明根源大概率在事务上下文里的参数污染，或者Dapper对事务内多语句批处理的参数绑定逻辑差异上。

核心原因分析 #

1. 事务内的参数上下文冲突 #

你之前在同一个事务中调用了QueryMultiple，Dapper在事务环境下会保留参数上下文的状态。当后续执行ExecuteAsync时，之前QueryMultiple用到的参数可能没有被完全清理，和当前的DynamicParameters混在一起，导致SQL语句实际接收到的参数数量、顺序和预期不匹配，最终触发"列值数量不匹配"的错误——看起来像是列定义的问题，实则是参数映射错位。

2. 多语句批处理+事务的参数绑定差异 #

你的SQL是包含创建临时表、插入、查询、删除临时表的多语句批处理，在非事务场景下，Dapper的参数绑定是独立的；但在事务上下文里，Dapper对批处理语句的参数解析逻辑可能存在隐式的上下文共享，导致@ParamX占位符没有正确对应到你传入的参数值。

结合你排查结果的验证 #

你已经找到的两个有效解决方法刚好印证了上面的推测：

• 移除事务后错误消失：脱离事务上下文后，Dapper每次操作的参数绑定都是独立的，不会受到之前操作的参数残留影响，批处理SQL就能正常执行。
• 替换QueryMultiple为DataAdapter Fill：QueryMultiple是Dapper封装的方法，会在事务内持有参数上下文；而DataAdapter是ADO.NET原生实现，不会和Dapper的参数上下文产生冲突，从根源上避免了参数污染。

保留事务的优化建议 #

如果业务需要保留事务，还可以试试这些方案：

• 显式指定命令类型：给ExecuteAsync加上commandType: CommandType.Text，确保Dapper正确识别多语句批处理：

  insertedId = await connection.ExecuteAsync(query, param, transaction, commandType: CommandType.Text);
  

• 隔离参数实例：每次执行数据库操作时，创建全新的DynamicParameters实例，不要复用之前操作的参数对象，避免上下文残留。
• 拆分批处理为独立操作：把多语句SQL拆成三个独立的Dapper调用，在同一个事务内依次执行，彻底规避批处理的参数绑定问题：

  // 插入Good并返回自增ID
  var goodId = await connection.QuerySingleAsync<int>(
      "insert into [Good] (Code, Title, GoodEnumId, Date, IsActive, IsDeleted) output inserted.Id values (@Param2, @Param3, @Param4, @Param5, @Param6, @Param7)",
      param, transaction);
  
  // 插入PaperDetail
  await connection.ExecuteAsync(
      "insert into [PaperDetail](GoodId, Length, Width, Grammage, Date, IsActive, IsDeleted) values (@GoodId, @Param8, @Param9, @Param10, @Param11, @Param12, @Param13)",
      new { GoodId = goodId, Param8 = param.Get<int>("Param8"), Param9 = param.Get<int>("Param9") /* 其他参数 */ }, 
      transaction);
  

内容的提问来源于stack exchange，提问作者n.y