Redis 常用命令时间复杂度：哪些操作会悄悄拖慢实例
Redis 很快，但“快”并不等于所有命令都是 O(1)。 一次 GET 通常很轻，一次 ZRANGE 可能返回十万个成员，一次 SINTER 可能扫描几个大集合，一次 DEL 也可能为了释放大 key 在主线程上忙很久。它们都只是一条 Redis 命令，对实例造成的压力却完全不同。 这也是线上 Redis 延迟偶尔尖刺时最容易被忽略的地方：QPS 没有明显上涨，CPU 看起来也不算很高，但某个请求做了一次与数据规模相关的 O(N) 操作，后面的请求就一起排队了。 这篇文章按 Redis 的常用数据类型整理时间复杂度。目的不是背完整张命令表，而是学会看到命令时迅速判断两件事：它会扫描多少数据，又会返回多少数据。 如果还不熟悉 Hash、quicklist、intset、listpack 和 skiplist 的关系，可以先看Redis 底层数据结构。底层结构正是这些复杂度的来源。 读复杂度之前，先认识几个变量 后面的表格会反复使用这些字母： 变量 含义 K 一次命令传入的 key 数量 N 当前集合、列表、Hash 或 ZSet 的元素总数 M 本次返回、删除或处理的元素数量 S 为了到达起始位置需要跨过的元素数量 B 需要读取、复制或传输的字节数 比如 ZRANGE rank 0 9 的复杂度是 O(log N + M)：先在有序结构中定位起点，再返回 M 个成员。排行榜里有一百万个人并不可怕，只取前十名依然很轻；真正危险的是 ZRANGE rank 0 -1，因为这时 M 也变成了一百万。 还有三个容易被大 O 记号藏起来的事实。 ...