Dapper本身不支持分库分表，所谓“Dapper Sharding”是开发者基于其封装的路由决策、多数据源管理与事务协调策略，核心在于写入前精准派发SQL到目标物理库表。
在分库分表场景下，Dapper 本身并不原生支持 Sharding（分片），它只是一个轻量级的 ORM 工具，专注于 SQL 映射与结果集映射。所谓“Dapper Sharding”并非官方功能，而是开发者基于 Dapper 封装的分库分表写入策略，核心在于**路由决策 + 多数据源管理 + 事务协调**。实现的关键不在于 Dapper 本身，而在于你如何在调用 Dapper 前，把 SQL 和参数精准地派发到正确的物理库表。
分库分表写入的核心前提：明确路由规则
写入前必须确定目标库和目标表，常见依据包括：
- 业务主键（如 user_id、order_id）做哈希或范围取模，映射到指定分片
- 时间字段（如 create_time）按月/年分表，结合租户 ID 或区域码选库
- 显式传入分片键（shard_key）并由路由组件解析，避免依赖固定字段
⚠️ 注意：若写入语句含 JOIN 或跨分片关联，需提前拆解为单分片操作，或改用归档/宽表等替代方案。
多数据源切换：动态连接字符串 + IDbConnection 管理
Dapper 操作依赖 IDbConnection，因此分库本质是为每次写入选择正确的连接实例：
- 预热多个 DbConnection 实例（按库名缓存），避免每次新建开销
- 封装 ConnectionFactory：输入逻辑库表名 → 输出对应物理连接
- 用 AsyncLocal 或 Scope 上下文透传当前分片上下文，确保嵌套调用不串库
示例逻辑：var conn = ConnectionFactory.GetConnection("user_db_001", "user_info_03");，再传给 conn.ExecuteAsync(...)。
分布式事务与一致性保障
跨库写入天然脱离单数据库事务边界。常见务实策略：
- 本地事务 + 最终一致：各分片独立提交，失败时记录补偿任务（如发 MQ 重试）
- TCC 模式：将写入拆为 Try（预占）、Confirm（提交）、Cancel（回滚）三阶段，Dapper 执行各阶段 SQL
- Saga 模式：长事务拆为子事务链，每个子事务用 Dapper 执行，失败触发反向操作
不推荐强依赖两阶段提交（2PC），因多数分库中间件（如 ShardingSphere）已屏蔽该复杂度，应用层应以柔性事务为主。
写入性能与安全细节
高频写入场景下需关注：
- 批量插入优先用
ExecuteAsync(sql, list)而非循环单条，减少网络往返 - 禁用自增主键全局依赖，改用雪花 ID、UUID 或号段模式生成分布式主键
- SQL 拼接务必使用 Dapper 参数化查询（
@param），防止路由键注入导致写错表 - 监控分片负载，避免某库写入倾斜（如用户 ID 连续注册导致哈希热点）
基本上就这些——Dapper 不负责分片，但足够灵活让你把分片逻辑干净地织进去。关键不在工具，而在路由清晰、连接可控、事务有兜底。
