Redis MGET分批阈值不能固定设为100或1000，需结合MTU、key长度和客户端限制动态估算，推荐按slot分组后每批50–100 key并发执行，并优先优化数据模型避免跨slot查询。
Redis MGET分批阈值为什么不能拍脑袋定
直接设成100或1000是常见错误。MGET本身不阻塞Redis主线程，但单次请求过大（比如上万key）会显著拉高单次网络包体积、服务端解析开销和客户端内存占用，反而拖慢整体吞吐。更关键的是，MGET在集群模式下要求所有key落在同一slot，批量越大，越容易触发CROSSSLOT错误——这不是性能问题，是直接失败。
怎么算出安全的分批上限
分批阈值不是固定值，得结合三个现实约束动态估算：
- 网络MTU：默认以太网MTU为1500字节，Redis协议有额外开销，单个
MGET命令建议控制在8KB以内（含key名长度），否则可能被TCP分片或触发客户端缓冲区警告 - key命名长度：比如
user:10001比u1多占10字节，1000个长key轻松突破包大小限制 - Redis版本与配置：
proto-max-bulk-len（默认512MB）虽宽松，但老版本客户端（如Jedis 3.x）对大响应体处理不稳定，实测超过5000个key易OOM
简单估算公式：分批数 = ceil(总key数 × 平均key长度 / 8000)。例如平均key长32字节，10000个key ≈ 400KB，按8KB/批，至少分50批；但实际应向下取整到更保守的值，比如30–50批。
生产环境推荐的分批策略
不要用固定数字一刀切，优先按slot分组再分批：
- 先用
CLUSTER KEYSLOT key或客户端getSlot(key)方法，把待查key按槽位分桶 - 每个槽内再按
50–100个key一组调用mget（10–100区间性能衰减明显，选中间值较稳） - 并发执行各slot批次，但控制总并发数≤
4（避免客户端连接池耗尽） - 对超长key（>64字符）单独打标，强制拆更小批次，防止单批包超限
示例伪代码：
r.mget(['user:1001', 'user:1002', ...]) # 每批≤80个，且确保全在同一slot
比“分批”更根本的优化点
很多人卡在“怎么分批”，其实问题常出在源头设计：
- 如果业务总要查“某类用户全部ID”，说明数据模型没做Hash聚合——改用
HGETALL user_group:{gid}或HMGET user_group:{gid} id1 id2...，键数量直接从N降到1 - 若必须用String键，key里加
{hashtag}前缀（如user:{202610}:1001），强制相关key落同一slot，避免CROSSSLOT打断分批逻辑 -
MGET失败时别重试整批，记录失败key单独补查——None值要跟业务约定是否可接受，避免盲目重试放大压力
真正卡住系统的，往往不是MGET本身，而是key分布混乱+无slot意识+不分批还硬扛上万key。分批只是止痛药，建模和分片设计才是根治手段。
