c#如何实现数据库读写分离_c#数据库读写分离新手必看入门教程-C#.Net教程-PHP中文网

真正可行的主从路由方案是封装 IDbConnection 代理层，通过 AsyncLocal 标记上下文并确保同一请求共享物理连接；事务必须在开启前确定主库连接，EF Core 的 SaveChangesAsync 默认走主库，Dapper/MyBatis-Net 需统一收口连接创建。

c#如何实现数据库读写分离_c#数据库读写分离新手必看入门教程

怎么在 C# 里让读操作走从库、写操作走主库

靠手动判断 SQL 类型或方法名来路由不现实，也容易出错。真正可行的方式是封装一个 IDbConnection 的代理层，在连接创建时根据当前上下文（比如方法调用栈、AsyncLocal 标记）决定连哪个数据源。

常见错误是直接在业务层用两个不同 DbContext 实例分别连主从库，结果事务一跨就崩——因为 SqlTransaction 不支持跨连接，更别说跨实例了。所以必须保证：同一请求内所有数据库操作共享同一个物理连接实例，且该连接的指向（主 or 从）在入口处就确定好。

读写分离的前提是主从同步延迟可控，否则 INSERT 后立刻 SELECT 可能查不到刚写入的数据
不是所有查询都适合走从库：SELECT ... FOR UPDATE、WITH (UPDLOCK) 这类带锁读必须走主库
EF Core 6+ 提供了 DbContext.Database.GetDbConnection()，但不能直接换掉底层 DbConnection 对象，得重写 DbConnection 子类并接管 OpenAsync

EF Core 中如何动态切换主从连接字符串

别碰 DbContextOptionsBuilder.UseSqlServer() 的硬编码字符串，它在 Startup 或 Program.cs 里就固定了。应该把连接字符串工厂抽出来，让每次创建 DbContext 实例前先判断当前是否需要读库。

典型做法是用 IServiceProvider 注册一个 IConnectionStringResolver，内部通过 AsyncLocal 记录当前是否处于“只读上下文”中。这个标记通常由中间件、AOP 拦截器或仓储方法命名约定触发（例如方法名含 Get、List、Find）。

避免用线程静态变量（ThreadStatic），ASP.NET Core 是异步模型，AsyncLocal 才能穿透 await
连接字符串不能拼接用户名密码，要用 SqlConnectionStringBuilder 安全合并
如果用了连接池，主从库的连接字符串必须完全不同（哪怕只是 Data Source 不同），否则会复用同一个池子导致路由失效

为什么事务里不能自动切到主库

EF Core 的 BeginTransaction() 默认绑定当前 DbConnection，而连接一旦打开，就不能再“切换”目标服务器。也就是说，如果你在事务中执行了第一个命令才决定要读主库，已经晚了。

"避开 C# 常见错误——空陷阱、异步陷阱、LINQ 陷阱及资源泄漏。"

下载

正确做法是在事务开启前就明确连接归属。比如封装一个 UnitOfWork.BeginWriteTransaction() 和 UnitOfWork.BeginReadTransaction()，后者其实只是占位（因为从库不支持写事务），前者才真正调用底层 BeginTransaction() 并强制使用主库连接。

任何显式调用 context.Database.BeginTransaction() 的地方，都意味着你已进入写上下文，后续所有操作必须走主库
EF Core 的 SaveChangesAsync() 内部会自动开事务，所以只要调用了它，当前 DbContext 就默认绑定主库
不要试图在 SaveChangesAsync() 后立刻用另一个 DbContext 去从库查新数据——这是典型的“幻读”，得靠应用层加缓存或等待同步延迟窗口

MyBatis-Net 或 Dapper 场景下怎么处理

这类轻量 ORM 没有 EF 那套生命周期管理，反而更容易控制连接来源。关键是把 IDbConnection 的创建逻辑收口，而不是把连接字符串塞进每个 new SqlConnection(...) 里。

推荐做法是提供一个 DbConnectionFactory，对外暴露 CreateReadConnection() 和 CreateWriteConnection()，并在内部维护两个独立的连接池配置。Dapper 的扩展方法如 QueryAsync 接收的就是 IDbConnection，你传哪个，它就用哪个。