Redis supports lexicographic range queries on Sorted Sets (ZRANGEBYLEX, or ZRANGE with the BYLEX option). What must be true of the data for them to be meaningful, what is the interval syntax, and what are they used for?

## The precondition A Sorted Set orders by score first and by member bytes only as a tiebreak. Lexicographic range queries exploit the tiebreak — so they are only meaningful when the primary ordering key is constant, i.e. **every member has the same score** (0 is the conventional choice). This is a genuine trap: Redis does not check the precondition. If some members have score 0 and others score 5, `BYLEX` still returns *something*, and that something is not a lexicographic range over the whole set. There is no error, no warning — just wrong results in production. Enforce the invariant in the write path: one place that inserts, always with the same score, ideally a script or a wrapper function. ## Interval syntax Endpoints are not bare strings; each needs a marker byte: - `[value` — inclusive - `(value` — exclusive - `-` — negative infinity for strings (before every possible member) - `+` — positive infinity (after every possible member) So `ZRANGE idx - + BYLEX` is the whole set in order, and `ZRANGE idx "[b" "(d" BYLEX` is everything from `b` inclusive up to but not including `d`. **Prefix search** is the workhorse: `ZRANGE idx "[kot" "[kot\xff" BYLEX LIMIT 0 10`. The upper bound works because `\xff` is the highest byte, so `kot\xff` sorts after every string starting with `kot` that uses ordinary characters. With arbitrary binary members you would need a more careful upper bound, but for text this idiom is standard. `LIMIT offset count` paginates, exactly as with score ranges. Large offsets are expensive (the engine must walk them), which is precisely why cursor pagination — remember the last member and use `(lastMember` as the next `min` — is the better pattern. Companion commands: `ZLEXCOUNT key min max` counts a lexicographic range, and `ZREMRANGEBYLEX key min max` deletes one, which is how you drop an entire prefix (say, all entries for a retired namespace) in one command. ## Byte comparison, not text collation Comparison is raw byte comparison. Consequences you must design for: - **Case sensitivity**: `Zebra` sorts before `apple` because uppercase letters have lower byte values. An autocomplete built on raw user input will look broken. - **No locale awareness**: accented characters, ligatures and non-Latin scripts sort by their UTF-8 byte sequences, not by any language's alphabet. `é` does not sit next to `e`. - **No normalisation**: trailing whitespace, different Unicode normalisation forms, and full-width characters all produce distinct, distantly-sorted members. The standard remedy is to store a **normalised sort key plus the original payload** in one member, separated by a delimiter that cannot appear in the key: `"kotlinKotlin Programming42"`. You query on the normalised prefix and split the member to render the original text and its id. Choose the delimiter carefully — it must sort low so it does not disturb prefix boundaries, and it must be impossible in the normalised key. ## What it is good for **Autocomplete.** One key per index (or per language/tenant), members are normalised terms, a prefix range with `LIMIT 0 10` gives the suggestions. Cheap and predictable: O(log N + M) with M bounded by your limit. **Secondary index.** Members encode `sortValue:entityId` so the set is an ordered index over some string attribute — usernames, email domains, SKU codes — supporting range scans that a plain Set or Hash cannot express. **Cursor pagination.** Instead of `LIMIT 5000 50`, remember the last member of the previous page and query `ZRANGE idx "(lastMember" + BYLEX LIMIT 0 50`. Constant cost per page regardless of depth, and stable under concurrent inserts in a way offsets are not. **Bulk prefix deletion.** `ZREMRANGEBYLEX idx "[tenant42:" "[tenant42:\xff"` removes an entire logical partition in one command — though note that removing very many members is O(log N + M) and will block for M's duration. ## Limits worth stating This is a prefix index, not a search engine. It does no tokenisation, no stemming, no fuzzy matching, no infix or suffix search, and no relevance ranking. "Find terms *containing* x" requires indexing every suffix, which multiplies memory by the average term length — occasionally worth it for small vocabularies, usually a signal that you want a real search index. And because a lexicographic index lives in one key, it is not splittable across cluster nodes; sharding means multiple keys and merging results client-side.