分片键选择直接影响路由正确性
分片键（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<AppDbContext>(o =>
{
o.AddShardingTransaction(); // 支持跨库事务（XA 或 Saga）
o.AddEntityConfig<Order>()
.UseShardingQuery((_, connection) => connection.GetConnectionString("ShardConn"))
.AddShardingTableRoute(o => o.UseModSharding<Order>(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<t>.ToShardingListAsync()</t>自动归并，但不保证事务一致性，慎用于强一致场景
分片扩容时数据迁移和双写最难的不是代码，是状态同步
从 4 库扩到 8 库，本质是重新哈希。常见做法是“双写+读灰度”，但 C# 服务里容易漏掉几个关键状态点：
写操作必须同时落旧分片（按原路由）和新分片（按新路由），且需幂等——推荐用唯一业务键 + UPSERT，而非单纯 INSERT 读请求灰度期间，先查新分片，未命中再查旧分片，但要缓存“该记录不在新分片”的负向结果，避免重复穿透 迁移工具（如用 SqlKata + Dapper 批量导出导入）必须校验行数、MD5 校验和、时间戳范围，不能只信日志“完成” EF Core 的 ChangeTracker 可能因双写产生并发冲突，建议迁移期禁用跟踪：context.Orders.AsNoTracking().FirstOrDefaultAsync(...)
最易被忽略的是事务边界：跨分片双写无法用本地事务保证原子性，必须接受最终一致性，并设计补偿机制（如定时对账 Job）。分片本身不是银弹，它把数据库的扩展瓶颈，转移到了应用层的状态协调上。
