本文主要是介绍【总结】为什么ITOO学生端Redis采用list结构，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
在Redis的文档里，每一个命令的时间复杂度都用大O表示法进行了描述，还能知道各命令的具体性能会受什么因素影响。让我们来看看一些用例。
【常数】时间复杂度O(1)被认为是最快速的，无论我们是在处理5个元素还是5百万个元素，最终都能得到相同的性能。对于sismember命令，其作用是告诉我们一个值是否属于一个集合，时间复杂度为O(1)。sismember命令很强大，很大部分的原因是其高效的性能特征。许多Redis命令都具有O(1)的时间复杂度。
【对数】时间复杂度O(log(N))被认为是第二快速的，其通过使需扫描的区间不断皱缩来快速完成处理。使用这种“分而治之”的方式，大量的元素能在几个迭代过程里被快速分解完整。zadd命令的时间复杂度就是O(log(N))，其中N是在分类集合中的元素数量。
【线性】时间复杂度O(N)，在一个表格的非索引列里进行查找就需要O(N)次操作。ltrim命令具有O(N)的时间复杂度，但是，在ltrim命令里，N不是列表所拥有的元素数量，而是被删除的元素数量。从一个具有百万元素的列表里用ltrim命令删除1个元素，要比从一个具有一千个元素的列表里用ltrim命令删除10个元素来的快速（实际上，两者很可能会是一样快，因为两个时间都非常的小）。
根据给定的【最小和最大的值】的标记，zremrangebyscore命令会在一个分类集合里进行删除元素操作，其时间复 杂度是O(log(N)+M)。这看起来似乎有点儿杂乱，通过阅读文档可以知道，这里的N指的是在分类集合里的总元素数量，而M则是被删除的元素数量。可 以看出，对于性能而言，被删除的元素数量很可能会比分类集合里的总元素数量更为重要。
对于sort命令，其时间复杂度为O(N+M*log(M))。
这是我为什么用list结构的原因，因为ltrim命令具有O(N)的时间复杂度。
因为现在的底层只有get，set这种散列数据结构，把一个list以一个关键字的形式存储，每次想查找里面的数据都得把数据导出来然后筛选完了重新放进去，这样子的效率总是觉得很低。
这篇关于【总结】为什么ITOO学生端Redis采用list结构的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
