使用Dapper SqlBuilder设置事务隔离级别失效问题咨询

嘿，我来帮你分析下为什么你用SqlBuilder把隔离级别设置和查询放一起没生效的问题，顺便给你几个靠谱的解决方案~

你遇到的核心问题其实和SQL语句的解析逻辑、Dapper对多语句批处理的处理方式有关，咱们一步步拆解：

首先看你第一种写法里的SQL：

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED SELECT * FROM Users SET TRANSACTION ISOLATION LEVEL READ COMMITTED

这里最大的问题是没有用分号分隔各个SQL命令！SQL Server解析的时候，根本分不清SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED到哪里结束，后面的SELECT会被当成这个SET语句的一部分，导致隔离级别设置根本没生效，查询自然还是用默认的READ COMMITTED。

就算你加上分号把语句拆成三段，用单批处理执行还是有隐患：Dapper的Query<T>方法本来就是为查询设计的，虽然它会执行批处理里的所有语句，但会话级别的隔离级别设置可能会和批处理的执行顺序有冲突——比如SQL Server可能会优化执行流程，导致隔离级别没来得及作用到查询上。

而你分开执行的方式之所以能成，是因为：先通过Execute单独执行SET语句，把当前连接的会话隔离级别改成READ UNCOMMITTED，然后执行查询的时候，查询就会用上这个级别，最后再把级别改回去，整个流程的会话状态是明确可控的。

方案1：用显式事务控制隔离级别（首推！） #

这是最安全清晰的方式，隔离级别只作用于当前事务，不会污染整个会话，还不用手动重置级别：

using (var transaction = conn.BeginTransaction(System.Data.IsolationLevel.ReadUncommitted))
{
    try
    {
        var result = conn.Query<User>("SELECT * FROM Users", transaction: transaction);
        transaction.Commit();
    }
    catch
    {
        transaction.Rollback();
        throw;
    }
}

事务结束后，连接的隔离级别会自动回到原来的状态，完全不用担心后续操作受影响。

方案2：修正SQL分隔符（仅作验证，不推荐生产用） #

如果你非要试试单批处理的方式，先把SQL语句用分号隔开：

var builder = new SqlBuilder();
var sqlStatement = builder.AddTemplate(@"
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SELECT * FROM Users;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
");
var result = conn.Query<User>(sqlStatement.RawSql);

但这种方式还是有不确定性，比如连接池的回收机制可能会干扰会话级别，所以不建议在生产环境用。

方案3：保留分开执行的方式（适合简单场景） #

如果你不需要事务，保持你原来的写法也可以，但最好注意连接的生命周期：

conn.Execute("SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED");
var result = conn.Query<User>("SELECT * FROM Users");
conn.Execute("SET TRANSACTION ISOLATION LEVEL READ COMMITTED");

不过要小心：如果查询过程中连接被意外回收，可能会导致隔离级别没被重置，影响后续使用这个连接的操作。

内容的提问来源于stack exchange，提问作者stack247