Redis Cheat Sheet

Eight Redis commands for the operations you meet first

This Redis commands cheat sheet is a searchable reference table for a deliberately small core: strings, keys, lists, and sets. It helps when recalling whether list insertion is LPUSH, checking the basic shape of SET key value, or distinguishing SADD from SMEMBERS. The page is not a complete mirror of the Redis command documentation; it presents eight commands with a short description and category.

The interface has one Search Commands field and a three-column table labeled Command, Description, and Category. Filtering happens immediately and ignores letter case. Search checks command syntax and description text, but not the category column. There are no category chips, copy buttons, version selectors, examples panel, or server connection.

How to search this compact reference

Enter a command name such as GET, an argument word such as key, or a concept from the description such as delete, prepend, or members. Matching rows remain in their original order. Searching value finds commands whose syntax or description contains that text. Searching lists does not match merely because a row’s category is Lists, unless the same text appears in its command or description.

Clear the search field to restore all eight rows. If no syntax or description contains the query, the table body is empty; the component does not show a separate “no results” message. Use the sheet as a mnemonic, then consult the command’s official documentation for options, complexity, version behavior, ACL category, cluster implications, and exact return type.

Strings: SET and GET

SET key value stores a string value under a key. Redis strings can hold text, serialized data, or binary bytes, subject to Redis limits. The simple form shown omits powerful options such as expiration, conditional writes, and returning the previous value. A production cache write often looks conceptually like SET session:123 payload EX 900, but that extended signature is not displayed in the table.

GET key returns the string value for a key or a nil result when the key does not exist. It raises a wrong-type error if the key contains a non-string data type. GET does not deserialize JSON, refresh expiration, or distinguish a cache miss from every application-level absence by itself.

Use consistent namespacing such as session:<id> or product:<id>. Do not build keys from secrets unless exposure in operational tooling is acceptable. For caching, define ownership, TTL, invalidation, serialization, and maximum payload size before treating SET/GET as an architecture.

Key operations: DEL and EXISTS

DEL key deletes a key and its associated value. Redis can accept multiple keys even though this quick-reference row shows one placeholder. Deleting a very large collection may block while memory is reclaimed; UNLINK can be preferable when asynchronous deletion semantics fit. Cluster deployments also constrain multi-key operations by hash slot.

EXISTS key tests whether a key exists and returns an integer count. With one key, that is conventionally interpreted as 1 or 0. In modern Redis, multiple arguments count existing keys, including repeated names according to documented behavior. Existence says nothing about the data type or value, and an expiring key can disappear immediately after the check.

Avoid check-then-act race conditions. EXISTS followed by SET is not an atomic “create if absent”; use SET with the appropriate conditional option. Likewise, existence before GET usually adds a round trip without eliminating races. Let the read result represent a miss unless the application requires different semantics.

Lists: LPUSH and LPOP

LPUSH key value prepends one or more values to the left side of a Redis list. LPOP key removes and returns the leftmost element. Together they produce last-in, first-out behavior when both operations use the same end. A queue typically pushes at one end and pops at the other, or uses blocking/stream primitives depending on reliability requirements.

The sheet’s wording says LPOP removes and gets the first element. Modern versions can support a count argument, but the row shows the portable basic form. When the key is absent, pop returns nil. When the key holds another type, Redis returns a wrong-type error.

Lists are useful for bounded histories and simple work distribution, but a bare pop can lose work if a consumer crashes after removal. Reliable processing may require BLMOVE, streams, acknowledgments, retries, and dead-letter handling. Also watch unbounded list growth: establish trimming or retention rather than relying on memory pressure to solve it.

Sets: SADD and SMEMBERS

SADD key member adds one or more unique members to a set and returns how many were newly added. Re-adding an existing member does not duplicate it. Sets suit tags, membership, deduplication, and unordered relationships.

SMEMBERS key retrieves all members. It is convenient for small sets and risky for huge ones because the full result must be produced and transferred. Use incremental scanning patterns for large collections, and avoid assuming iteration order. If the key does not exist, the result is an empty collection; a key of the wrong type causes an error.

Membership checks, intersections, unions, random members, and removals are outside this table even though they are central to Redis sets. Search members finds SMEMBERS through its description; the page does not expand related commands.

Running commands safely

Before trying any Redis CLI command, confirm endpoint, logical database, authentication context, and environment. Production and development prompts can look identical. Start with read-only inspection when possible and avoid broad deletion patterns. DEL key in the sheet is a literal single-key example, not an invitation to combine shell expansion or a blocking key scan in production.

Understand return values. Redis CLI may display integers, bulk strings, arrays, nil values, or errors. Application drivers map these to language-specific types. Test that mapping, especially around nil versus empty data. Pipeline commands to reduce round trips when operations are independent; use transactions or Lua/functions only when their atomicity model is understood.

Record the Redis server version. Command options evolve, and managed services can restrict commands. ACLs may allow GET but deny DEL. Cluster mode affects multi-key behavior, replicas may be stale depending on read routing, and eviction can remove keys even before a TTL expires.

Performance is mostly about shape and scale

The listed commands are commonly fast for modest values, but Big-O labels alone do not protect a system. GET of a multi-megabyte value incurs allocation and network cost. DEL of a huge list or set can create latency. SMEMBERS scales with set cardinality and response size. Large LPUSH rates without trimming consume memory.

Use SLOWLOG, latency monitoring, memory analysis, command statistics, and application tracing to investigate behavior. Avoid KEYS in production scans; although it is not listed here, beginners often reach for it after learning key commands. Prefer SCAN with the understanding that it is incremental and may return duplicates during changes.

Cache keys need expiration strategy. This sheet’s SET signature omits TTL options, so copied syntax alone can create permanent keys. Measure hit rate and stale-data tolerance. Protect Redis with network controls and authentication; it should not be exposed publicly as a convenient command console.

Limits of this cheat sheet

Only these rows exist: SET, GET, DEL, EXISTS, LPUSH, LPOP, SADD, and SMEMBERS. Hashes, sorted sets, streams, pub/sub, transactions, scripting, geospatial indexes, HyperLogLog, bitmaps, server administration, persistence, replication, and cluster commands are absent. Descriptions are brief and do not include optional arguments.

The search does not tokenize or rank. It performs a case-insensitive substring match across syntax and description. set can match command text beyond the conceptual category you intended. Category values are displayed but not searchable. The table is scrollable with a fixed maximum height, though eight rows usually fit comfortably depending on viewport.

Failure patterns to recognize

A wrong-type error means a key already contains another Redis data structure. A nil GET or LPOP can mean absence, expiration, eviction, or concurrent consumption. Unexpected memory growth often means missing TTLs or unbounded collections. A slow SMEMBERS usually means the set is too large for whole-value retrieval. An EXISTS result can become stale before the next command because other clients continue operating.

Do not solve these by adding retries indiscriminately. Define idempotency, concurrency, timeouts, and backoff at the application boundary. The cheat sheet supplies spellings; operational correctness comes from data-model and failure-design work.

FAQ

Why are only eight commands shown?

The component is a focused starter reference, not the complete Redis catalog.

Can I search by category?

Not directly. Filtering checks command syntax and descriptions, not the Category value.

Does the page execute Redis commands?

No. It contains static reference rows and a local text filter; no server connection is made.

Why is there no command to set an expiration?

The displayed SET row shows only SET key value. Consult current Redis documentation for SET options and separate expiration commands.

Is SMEMBERS safe on any set?

No. It returns the entire set, so cardinality and response size matter. Use an incremental approach for large sets.

Are command examples version-specific?

They are basic signatures, but optional behavior can vary. Check the documentation for your deployed Redis version and provider.