Redis COMMAND INFO 怎样查看命令标志和复杂度

想知道 Redis 某个命令能不能读写、需要几个参数、键位在哪里，先用 COMMAND INFO 读取服务端元数据即可。它会返回命令名、arity、flags、键位置和 ACL 分类等信息；但 fast、slow 只是粗粒度标志，不是该命令完整的 O(...) 复杂度证明。精确复杂度要回到对应命令的官方说明。

官方地址：https://redis.io/docs/latest/commands/command-info/

COMMAND INFO 返回的到底是什么

COMMAND INFO 的查询对象是命令名，可以一次传一个，也可以连续传多个。返回结果会按请求的命令逐项对应：已知命令给出元数据，未知命令保留一个空项。它适合做能力探测、客户端提示或运维排查，不适合替代完整的命令语义文档。

先查一个命令，再批量查多个命令

最小查询可以从 GET 开始。下面的命令用于读者在隔离 Redis 环境中复现，注释只解释命令意图；本文没有连接数据库执行这些示例。

# 查询一个命令的服务端元数据，便于查看 arity、flags 和键位置
redis-cli COMMAND INFO GET

# 一次查询多个命令，返回项按 GET、SET 的请求顺序对应
redis-cli COMMAND INFO GET SET

# 查询不存在的命令，用于观察未知命令对应的空结果
redis-cli COMMAND INFO NOT_A_COMMAND

批量查询时不要把返回结果当成一条扁平记录。第一个结果对应第一个命令，第二个结果对应第二个命令；其中某个命令不存在时，仍然要保留它在原请求中的位置。客户端封装时应优先使用库对 RESP 数组和 nil 的结构化映射。

COMMAND INFO GET SET
GET  -> 已识别的命令元数据
SET  -> 已识别的命令元数据

COMMAND INFO NOT_A_COMMAND
NOT_A_COMMAND -> nil

flags 怎样帮助判断调用边界

常见 flags 可以作为“这条命令大致属于哪类操作”的线索。例如 readonly 表示只读属性，write 表示写入属性，fast 和 slow 表示 Redis 对命令执行特征的粗粒度标记。它们适合在客户端展示提示或排查误用，不应被当成完整的权限、事务或性能承诺。

ACL 分类 也不能等同于“当前用户一定能执行”。命令属于某个权限类别，只能帮助你理解 ACL 规则的匹配对象；最终结果还要结合用户被授予的命令类别、密钥模式和具体命令权限。

键位置同样要谨慎读取。简单命令可以用首键、末键和步长描述传统参数位置；涉及可移动键、子命令或复杂参数时，不能只拿几个整数就推断所有键。要做集群路由或客户端自动抽键，应该使用客户端已经支持的键规范，并把版本差异纳入兼容处理。

fast/slow 不等于精确复杂度

这是最容易误读的地方：看到 fast 不代表该命令永远是 O(1)，看到 slow 也不等于每次调用都会慢。flags 是分类信号，精确复杂度还要看具体命令的输入规模、扫描范围和参数。

例如 COMMAND INFO 自身的官方说明给出了“查询命令数量为 N 时为 O(N)”的复杂度；这描述的是元数据查询命令，不是它返回的每一个目标命令都具有同样的复杂度。目标命令的精确说明应从其官方命令页读取，不能从 fast/slow 反推完整的渐进式结论。

如果文章、监控或客户端需要展示复杂度，建议把“服务端动态元数据”和“官方文档中的静态语义”分开保存：前者用于判断当前服务端认得什么，后者用于解释资源成本与适用边界。

在客户端里怎样稳定解析

不要把所有回复都按固定下标直接转成业务字段。更稳妥的做法是保留三种状态：命令存在且有元数据、命令不存在得到 nil、请求本身失败得到错误。下面用伪代码展示判断思路，具体数组映射以你使用的 Redis 客户端为准。

// 该示例只展示解析分支；实际项目应使用客户端提供的结构化命令回复类型。
func classifyCommandInfo(name string, reply []any, err error) string {
	// 传输或权限错误必须单独返回，不能折算成“命令不存在”。
	if err != nil {
		return "request-error"
	}
	// 服务端对未知命令保留 nil 语义，调用方可以据此做能力降级。
	if reply == nil {
		return "unknown-command"
	}
	// 已知命令还要继续按客户端库的字段映射读取 flags 和键元数据。
	return "known-command"
}

生产代码还要考虑不同 Redis 版本返回字段的增减、模块命令、子命令和 RESP2/RESP3 的映射差异。兼容层应围绕字段名称或客户端结构体做适配，并记录版本信息；不要把一次测试环境的数组下标当作永久协议。

COMMAND INFO、官方命令页怎么分工

因此，排查一个命令“能不能用”时可以先发 COMMAND INFO，再把结果与目标命令的官方页面放在一起解释。如果服务端返回 nil，先处理版本、模块和命令拼写；如果返回元数据但调用报权限错误，就转向 ACL，而不是把 nil 的处理逻辑继续套用。

常见问题

COMMAND INFO 能直接返回命令的 O(1) 或 O(N) 吗？

普通返回主要是命令元数据和 flags。fast/slow 不是完整的渐进复杂度；精确 O(...) 结论应查对应命令的官方说明。

为什么批量查询不能只看一条结果？

返回项按请求的命令逐项对应，未知命令还可能占据一个 nil 位置。客户端必须保留输入顺序，不能因为中间项为空就错位。

查到 readonly 就代表任何用户都能执行吗？

不是。readonly 描述命令属性，能否执行仍受当前用户 ACL、密钥模式和实例配置影响。

COMMAND INFO 可以替代 COMMAND DOCS 吗？

不能。COMMAND INFO 适合运行时元数据探测，官方文档才负责完整语义、参数解释、示例和精确复杂度。

一句话总结：用 COMMAND INFO 看当前 Redis 认识什么、命令大致具有什么属性；用对应官方命令页解释它具体怎么工作、成本是多少。把这两层信息分开，客户端探测和性能判断都更稳。