根据ZRANGEBYLEX command的文档部分，有以下信息。如果在有序集中存储密钥为零分，则可以使用词典顺序检索以后的密钥。 ZRANGEBYLEX操作复杂度为O(log(N)+M)，其中N是总元素数，M是结果集大小。文档中有一些关于字符串比较的信息，但没有说明结构，其中将存储元素。
但经过一些实验和阅读source code后，可能ZRANGEBYLEX操作具有线性时间搜索，当ziplist中的每个元素将与请求匹配时。如果是这样，复杂性将比上面描述的更大 - 关于O（N），因为ziplist中的每个元素都将被扫描。
在使用gdb进行调试之后，在genericZrangebylexCommand函数中实现了ZRANGEBYLEX命令。控制流程继续在eptr = zzlFirstInLexRange(zl,&range);，因此元素检索的主要工作将在zzlFirstInLexRange函数执行。所有namings和跟随控制流都考虑使用ziplist结构，并且所有与输入操作数的比较都是逐个元素地顺序完成的。
在redis商店中插入众所周知的密钥后，通过分析检查内存，似乎ZSET元素实际存储在ziplist中 - 与gauge的每字节字节比较确认它。
那么问题 - 文档如何出错并在线性出现时会传播对数复杂度？或者ZRANGEBYLEX命令可能略有不同？提前致谢。
文档如何出错并在线性出现时呈现对数复杂性？
文档在很多情况下都是错误的，但它是一个持续的开源工作，您可以通过存储库（https://github.com/antirez/redis-doc）做出贡献。
或者ZRANGEBYLEX命令可能略有不同？
您的结论是正确的，因为排序集搜索操作（无论是否是词典编纂）在使用Ziplists进行编码时表现出线性时间复杂度。
然而。
Ziplists是一种优先选择CPU到内存的优化，这意味着它适用于小型集合（即低N值）。它通过配置控制（参见zset-max-ziplist-entries和zset-max-ziplist-value指令），一旦数据增长到指定的阈值以上，ziplist编码就会转换为skip list。
由于拉链很小（小Ns），因此可以假设它们的复杂性是恒定的，即O（1）。另一方面，由于它们的性质，跳过列表表现出对数搜索时间。 IMO意味着文档的完整性保持不变，因为它提供了最糟糕的案例复杂性。