分片键应选高频查询、高基数、不可变字段如UserId或TenantId，避免OrderId或CreatedTime；推荐复合键(TenantId,UserId)并确保查询带TenantId；禁用NULL或易变字段；哈希需用确定性算法；C#项目优先客户端方案如ShardingCore；跨分片查询需归并处理；扩容需双写+灰度+校验+最终一致性。
分片键选择直接影响路由正确性
分片键（Shard Key）必须是查询高频、高基数、不可变的字段，比如 UserId 或 TenantId。用 OrderId 作分片键容易导致热点——新订单集中写入单个库；用 CreatedTime 更糟，它天然倾斜且无法支持等值路由。
实际设计时优先选业务主键或租户标识，避免用自增 Id（除非配合雪花ID等全局有序但可哈希的生成方式）。分片键一旦选定，后续几乎无法安全变更，所以务必在第一个分片上线前确认好语义边界。
- 推荐组合：复合分片键如
(TenantId, UserId)，但需确保所有查询都带上TenantId，否则跨库扫描不可避免 - 禁止使用含空值、NULL 或频繁更新的字段（如
UpdatedAt）作为分片键 - 若用哈希分片，注意 .NET 中
GetHashCode()在不同进程/版本下不保证稳定，应改用System.Security.Cryptography.HashAlgorithm或XXHash等确定性算法
ShardingProxy vs 客户端直连：C# 项目该用哪一种
ShardingSphere-Proxy 是独立中间件，C# 应用无感知，但引入额外运维成本和网络跳数；客户端直连（如用 ShardingCore 或自研路由）更轻量，却要求你承担 SQL 解析、路由、结果归并逻辑。
中小团队、.NET 主栈项目，强烈建议从客户端方案起步。ShardingCore 支持 EF Core 5+，能自动拦截 DbContext 的查询与保存操作，只需配置分片规则和数据源映射：
services.AddShardingDbContext(o => { o.AddShardingTransaction(); // 支持跨库事务（XA 或 Saga） o.AddEntityConfig () .UseShardingQuery((_, connection) => connection.GetConnectionString("ShardConn")) .AddShardingTableRoute(o => o.UseModSharding (16)); // 按 OrderId % 16 分16库 });
- ShardingCore 不支持复杂子查询、UNION ALL 和部分窗口函数的自动路由，这类 SQL 会 fallback 到默认库执行
- 若已用 Dapper，也可基于
IDbConnection封装路由工厂，但需手动处理分页、排序、聚合的归并逻辑 - Proxy 方案虽省心，但 C# 服务无法利用连接池复用、无法细粒度控制超时和重试策略
跨分片查询（如分页、COUNT、SUM）必须显式降级处理
没有分布式查询引擎支撑时，SELECT COUNT(*) FROM orders WHERE status = 1 这类语句不能直接下推——每个分片返回局部结果后，应用层必须归并。这会放大延迟和内存压力，尤其当分片数多、单次查数千页时。
- 分页尽量用「游标分页」（
WHERE id > @lastId ORDER BY id LIMIT 100），避免OFFSET导致全表扫描 - COUNT 类统计走异步后台任务预计算 + 缓存（如 Redis），而非实时聚合
- 涉及
GROUP BY的聚合查询，先按分片键分组再归并，否则结果错误（例如按Region分组，但Region不是分片键） - ShardingCore 提供
IQueryable自动归并，但不保证事务一致性，慎用于强一致场景.ToShardingListAsync()
分片扩容时数据迁移和双写最难的不是代码，是状态同步
从 4 库扩到 8 库，本质是重新哈希。常见做法是“双写+读灰度”，但 C# 服务里容易漏掉几个关键状态点：
- 写操作必须同时落旧分片（按原路由）和新分片（按新路由），且需幂等——推荐用唯一业务键 + UPSERT，而非单纯 INSERT
- 读请求灰度期间，先查新分片，未命中再查旧分片，但要缓存“该记录不在新分片”的负向结果，避免重复穿透
- 迁移工具（如用 SqlKata + Dapper 批量导出导入）必须校验行数、MD5 校验和、时间戳范围，不能只信日志“完成”
- EF Core 的 ChangeTracker 可能因双写产生并发冲突，建议迁移期禁用跟踪：
context.Orders.AsNoTracking().FirstOrDefaultAsync(...)
最易被忽略的是事务边界：跨分片双写无法用本地事务保证原子性，必须接受最终一致性，并设计补偿机制（如定时对账 Job）。分片本身不是银弹，它把数据库的扩展瓶颈，转移到了应用层的状态协调上。
