You want to show a random sample of fields from a large Redis hash without pulling the whole thing. How does the Redis command HRANDFIELD serve that, how does its reply shape change with the WITHVALUES option under RESP2 versus RESP3, and how does it compare with HSCAN for the same job?

## What HRANDFIELD is for A Redis *hash* is a single key holding a set of field→value pairs, like a small dictionary stored under one name. When such a hash gets large, reading it whole with `HGETALL` costs O(N) in the number of fields and materialises the entire thing into one reply — expensive on the server and on the network. `HRANDFIELD` exists for the case where you do not want all of it: you want a handful of representative entries. Admin panels showing "a few example rows", debug endpoints, cache-warming that exercises random members, and approximate statistics over a very large hash are the everyday uses. Syntax: ``` HRANDFIELD key [count [WITHVALUES]] ``` With no count it returns one random field *name* (a bulk string), or a nil reply if the key does not exist. With a count it returns an array of field names, or an empty array for a missing key. Nothing is removed — it is a pure read, unlike `SPOP` on sets, which has no hash equivalent. The `count` argument uses the same positive-distinct / negative-with-replacement convention as `SRANDMEMBER` and `ZRANDMEMBER`; that convention and its reply-size implications belong to the sets material and are not re-derived here. ## Why the cost is independent of hash size The documented complexity is **O(count)** for the counted forms (effectively O(1) for the single-field form). Redis picks entries directly out of the hash's internal representation rather than walking it, so the amount of work scales with what you asked for, not with what is stored. This is the property that makes it safe on a huge key: `HRANDFIELD bigkey 10` on a ten-million-field hash does roughly the same work as on a ten-field hash, and does not block the single-threaded server the way an `HGETALL` over the same key would. Contrast that with `HSCAN`, whose per-call cost is bounded by the number of hash-table buckets visited for that cursor step, and whose *total* cost across a full iteration is proportional to the size of the collection. `HSCAN` is cheap per call and expensive in aggregate; `HRANDFIELD` is cheap because it never promises aggregate coverage at all. ## Reply shape: WITHVALUES under RESP2 vs RESP3 `WITHVALUES` may only be used together with a count. It makes Redis return each selected field's value as well, saving a follow-up `HMGET` round trip. The shape depends on the protocol the connection negotiated (RESP3 is opted into with the `HELLO 3` handshake, supported since Redis 6): - **RESP2** has only a generic array type, so the reply is a *flat* array: `[field1, value1, field2, value2, …]`. The client library — or your code — has to pair adjacent elements. - **RESP3** has a map type, so the server returns the pairs as a map (clients typically surface a dictionary, or an array of two-element pairs depending on the library). The practical consequence: any parsing that assumes the flat layout silently breaks if the client driver upgrades to or negotiates RESP3, and vice versa. Let the client library normalise the reply rather than indexing raw positions, and be aware that `ZRANDMEMBER … WITHSCORES` has exactly the same RESP2/RESP3 split. ## Ordering is not pagination The order of returned fields is unspecified. It is neither a stable ordering you can resume from nor a uniform shuffle of the whole hash. There is no cursor, no marker, and no guarantee that repeated calls will eventually cover every field — a given field may keep reappearing and another may never appear. Building "page through the hash by calling HRANDFIELD repeatedly and de-duplicating" produces a loop with unbounded runtime and no completion condition. If a UI needs *browse* semantics, that is `HSCAN`. ## HRANDFIELD samples, HSCAN enumerates The two commands answer different questions and are not interchangeable: | | HRANDFIELD | HSCAN | |---|---|---| | Purpose | sample | enumerate | | Cost | O(count), independent of hash size | bounded per call by buckets visited; O(N) over a full iteration | | Guarantee | none about coverage | every element present for the whole iteration returned at least once | | Duplicates | possible (with a negative count, by design) | possible across cursor steps | | Resumable | no cursor | cursor-based, resumable | | Randomness | random selection | traversal order, not random | Choose by guarantee: if the requirement contains the word *every*, use `HSCAN`; if it contains *a few* or *random*, use `HRANDFIELD`. A common design mistake is reaching for `HRANDFIELD` because it "feels lighter" when the actual requirement was full traversal — the code then quietly misses fields. One further limit: since `HRANDFIELD` does not remove anything, "take a random field and delete it" is `HRANDFIELD` followed by `HDEL`, which is two commands with a race window between them; making it atomic needs a small Lua script.