TYPE命令返回的是逻辑类型而非底层编码，如TYPE为hash时底层编码可能是listpack；需用OBJECT ENCODING命令查看真实编码，不同编码影响内存与性能。
TYPE 命令返回的类型名和实际底层编码不是一回事
很多人看到 TYPE 返回 string 就以为这 key 一定用的是简单动态字符串（SDS），其实不对。Redis 的 TYPE 只反映**逻辑类型**，比如用户存的是字符串、列表、哈希等抽象结构；而底层真正用什么编码（如 int、embstr、raw、quicklist、ziplist、listpack、hashtable 等）得靠 OBJECT ENCODING 查。比如一个只有 3 个元素的小哈希，TYPE 是 hash，但 OBJECT ENCODING 很可能是 listpack —— 这直接影响内存占用和遍历性能。
常见错误现象：
• 用 TYPE 判断是否“适合用 INCR”却失败：因为 key 是 string 类型但值不是数字格式，报 ERR value is not an integer or out of range
• 看到 list 就以为 LLEN 快如闪电，结果发现是老版本用的 ziplist 编码，大 list 下 LINDEX O(N) 慢得明显
- 查逻辑类型用
TYPE，查真实存储结构必须补一句OBJECT ENCODING <key> - 6.2+ 版本中，
hash和zset默认用listpack，list默认用quicklist；老版本（ - 如果只是想确认能否执行某操作（比如
HGETALL），只看TYPE足够；但做性能调优或排查内存异常，不看ENCODING就等于蒙眼开车
批量查 TYPE 要避开 KEYS + TYPE 的组合陷阱
线上环境禁用 KEYS *，这是常识；但有人改用 SCAN 配合循环调 TYPE，以为安全了——其实照样可能阻塞。因为每次 TYPE 都要查 key 元数据，高频小 key 扫描时 CPU 和指令数并不低，尤其在 key 数量级达百万以上时，客户端延迟肉眼可见。
使用场景：
• 运维巡检，想统计各类型 key 占比
• 上线前验证迁移脚本是否把 string 错写成 hash
- 优先用
redis-cli --scan --pattern "*" | xargs -L 100 -P 4 redis-cli type控制并发和批处理量，别裸写 while loop - Redis 7.0+ 支持
SCAN的TYPE参数（如SCAN 0 TYPE string），能直接过滤，比客户端过滤高效得多 - 如果只是粗略估算，可以用
INFO keyspace看 db0:keys=1234,expires=567,avg_ttl=89000 —— 它不告诉你类型，但能快速排除空库或过期 key 泛滥的情况
TYPE 返回 none 表示 key 不存在，但要注意 Lua 脚本里的 nil 处理
在 Redis 原生命令里，对不存在的 key 执行 TYPE 明确返回 none，很好理解。可一旦进 Lua 脚本，redis.call("TYPE", KEYS[1]) 返回的是 Lua 字符串 "none"，不是 Lua 的 nil。有人误判为 if not res then，结果逻辑永远走不到 else 分支。
常见错误现象：
• Lua 脚本里用 type(res) == "nil" 判断 key 是否存在 → 实际是 string
• 在 EVAL 中拼接命令时，把 "none" 当作空值参与后续计算，导致类型错误
- Lua 里统一用
res == "none"判断 key 不存在，别信not res或type(res) - 如果脚本里需要“存在才操作”，建议先用
EXISTS，它返回 0/1 更符合布尔直觉，且比TYPE少一次字符串比较开销 - 集群模式下，
TYPE对跨 slot 的 key 会报MOVED错误，Lua 里没捕获的话整个脚本就中断 —— 不是返回none
用 TYPE 做业务路由时，别忽略过期 key 的中间态
有些服务用 TYPE 结果决定走哪条业务分支：比如 string 走配置读取，hash 走用户属性合并。但如果这个 key 正处于过期过程中（比如刚被访问触发惰性删除，或后台线程正在清理），TYPE 仍可能返回旧类型，紧接着 GET 或 HGETALL 就返回 nil —— 路由没错，但下游拿不到数据。
性能影响：
• 惰性删除本身不耗时，但 TYPE 查的是 key 元信息，只要 key 还在 dict 里就返回类型，不管 value 是否已标记为待删
• 这种“类型存在但值为空”的状态，在高并发 + 短 TTL 场景下出现概率明显升高
- 关键路径上别单靠
TYPE做决策；要么加一层EXISTS，要么直接尝试目标命令并捕获空响应 - 监控时注意
expired_keys和evicted_keys指标突增，这类中间态问题往往伴随它们上升 - 如果业务允许，把 TTL 设长一点，或改用
PEXPIREAT配合毫秒级精度控制，减少“刚好卡在过期窗口”的概率
TYPE 看似简单，但线上出问题时，八成不是命令不会用，而是没意识到它不保证 value 存活、不反映底层编码、不处理集群重定向、也不对 Lua 的 nil 做友好适配 —— 这些点藏得深，查日志时容易漏掉。
