row_number() % n 不是真正的负载均衡，因其静态编号、无视节点负载与状态、不支持动态重试和读写分离，仅适用于离线批处理等低风险场景；生产环境应使用always on只读路由、dbproxy或连接池策略。
SQL 窗口函数本身不提供负载均衡能力，也不能替代网络层或中间件的流量分发逻辑；用 ROW_NUMBER() 配合 MOD 实现的只是「伪轮询式数据路由」，仅适用于极轻量、无状态、且能容忍数据不一致的离线/批处理场景。
为什么不能把 ROW_NUMBER() % N 当作真实负载均衡
这种写法本质是按查询时的行序做静态编号再取模，完全不感知节点实际负载、连接数、响应延迟或可用性：
-
ROW_NUMBER()每次执行结果依赖ORDER BY子句——若没显式指定，行为未定义；即使指定了，排序开销也可能压垮查询本身 - 取模值固定绑定到某一行，无法动态重试失败节点（比如某副本已宕机，但
MOD还会把它算进去） - 不支持读写分离：所有语句都走同一套编号逻辑，
INSERT和SELECT无法自动分流 - 并发下无事务隔离保障：两个并行查询对同一张表跑
ROW_NUMBER() OVER(ORDER BY id)，可能因快照版本不同导致编号错位
什么情况下可以勉强一试
仅限以下三类低风险场景，且必须配合应用层兜底：
- ETL 批量导出分片：例如将大表
orders拆成 4 份交给 4 个下游服务处理，SQL 示例：SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (ORDER BY order_id) AS rn FROM orders ) t WHERE rn % 4 = 0;
- 测试环境模拟请求分发：用视图包装
ROW_NUMBER() % N做硬编码路由，但绝不用于生产 - 只读报表临时分流：当只读副本间数据延迟可接受（如小时级），且业务允许部分结果缺失时，可结合
TRY...CATCH+ 重试逻辑绕过不可用节点
真正该用的替代方案
生产环境必须交由更可靠的机制处理：
- SQL Server 原生方案优先选
Always On可用性组 + 只读路由侦听器，配置READ_ONLY_ROUTING_LIST后，客户端连接字符串加ApplicationIntent=ReadOnly即可自动分流 - 中间件层推荐
DBProxy或HAProxy，用健康检查脚本（如检测SELECT @@SERVERNAME是否返回）实时剔除故障节点 - 应用层直连多实例时，避免手写
MOD，改用连接池内置策略：例如 .NET 的SqlConnectionStringBuilder支持Connection Timeout和重试，Python 的pyodbc可封装带熔断的连接工厂
用 ROW_NUMBER() 做负载均衡，就像用尺子量电流——函数没错，但用错了地方。真正的瓶颈从来不在 SQL 写法，而在连接管理、故障探测和路由决策的实时性上。
