PUBSUB CHANNELS命令本身不慢，执行延迟高实为Redis主线程被KEYS、SCAN、AOF重写等阻塞所致；返回空列表仅表示无匹配活跃频道，非命令变慢。
PUBSUB CHANNELS 命令本身几乎不会变慢——它只是遍历内存中一个固定结构 pubsub_channels 哈希表，时间复杂度是 O(N)，N 是当前匹配 pattern 的活跃频道数。如果你观察到该命令执行延迟明显（比如 >1ms），那问题一定出在别处，不是命令逻辑本身。
PUBSUB CHANNELS 执行慢 ≠ 命令慢，而是环境被拖累
Redis 是单线程处理所有命令的，PUBSUB CHANNELS 会排队等待前面的命令执行完。所以“慢”通常是阻塞型操作正在执行，而非这个命令自身耗时高。
- 常见干扰源：
- 正在执行大量
KEYS、SCAN（尤其KEYS *）导致主线程卡住数百毫秒 - 大量慢日志堆积且
slowlog-max-len过大（如设为 10000），每次写入慢日志需遍历链表清理旧条目 - 内存紧张触发
eviction策略扫描，尤其是allkeys-lru在 key 数量极大时开销显著 - AOF rewrite 或 RDB save 正在进行（虽然子进程不阻塞主线程，但 fork 开销 + 页面写时复制可能引发短暂抖动）
- 正在执行大量
你可以用 SLOWLOG GET 5 查最近几条慢命令，重点看有没有 KEYS、CONFIG REWRITE、BGREWRITEAOF 等高开销操作紧邻 PUBSUB CHANNELS 出现。
为什么 PUBSUB CHANNELS pattern 返回为空，却误判为“执行慢”
这是最常被忽略的误判点：命令返回空列表 [] 不代表它卡住了，只代表此刻没有匹配该 pattern 的活跃频道。
- 频道不是 key，不持久化，没人订阅就不存在
-
PUBSUB CHANNELS "log:*"返回空，常见原因：- 所有订阅者已断连（未
UNSUBSCRIBE就直接关闭连接，Redis 会在连接释放时自动清理） - 订阅者用的是
PSUBSCRIBE模式匹配，而PUBSUB CHANNELS只查精确频道名，不查模式 - pattern 大小写不一致，比如写了
"Log:*"但实际频道是"log:err"
- 所有订阅者已断连（未
验证方式：先用 PUBSUB NUMSUB log:err 看具体频道是否有订阅者；再用 CLIENT LIST 过滤 cmd=subscribe 查当前活跃订阅连接。
Python 调用时 decode 错误会让“快命令变慢感知”
r.execute_command('PUBSUB CHANNELS', 'log:*') 返回的是字节列表，比如 [b'log:err']。如果后续代码做了耗时 decode（比如错误地用 str(c) 或反复 c.decode('utf-8') 重试），会把网络往返快、命令执行快的优势全抵消。
- 正确做法（一行完成，无异常分支）：
[c.decode() for c in r.execute_command('PUBSUB CHANNELS', 'log:*')] - 错误示范（性能+语义双坑）：
str(c) # 得到 "b'log:err'"，不是字符串频道名
c.decode('utf-8', errors='replace') # 无必要容错，除非你真收过非 UTF-8 频道名（极罕见）
注意：旧版 redis-py（<3.5.3）的 r.pubsub_channels(pattern=...) 方法内部没做 decode，返回仍是 bytes，容易在日志里看到一堆 b'xxx' 以为是 bug。
真正要盯住的，从来不是 PUBSUB CHANNELS 这个命令本身，而是它执行前后 Redis 主线程是否被其他重量级操作抢占。它的响应时间，本质是 Redis 整体健康度的一面镜子。
