做了一个sql查询，还通过了获取的数组下标来排序。但是前辈说会有大量访问的时候这样很消耗内存，网上看了下好多说的方法是做cache，有没有其他的方法处理呢？
回复讨论(解决方案)
你的语句，不会很消耗内存。activeNum是索引就可以了。
当然有cache是最好的。
你的语句，不会很消耗内存。activeNum是索引就可以了。
当然有cache是最好的。
要是有几十万上百万的数据，每次有人访问index就去取一次不会消耗资源吗？
如果加索引的话，加什么索引好呢？这个字段是随时变化的
你的语句，不会很消耗内存。activeNum是索引就可以了。
当然有cache是最好的。
要是有几十万上百万的数据，每次有人访问index就去取一次不会消耗资源吗？
如果加索引的话，加什么索引好呢？这个字段是随时变化的
如果数据值是唯一的 就加唯一索引 否则加普通索引
如果mysql表数据多 几百万的时候 那需要考虑分表
1、没看到 数组下标来排序 的代码
2、activeNum 上应有索引（普通索引即可）
3、你知道访问数据库和访问 cache 的区别吗？
将数据库的压力转嫁到 cache 就一定合适吗？
如果有有几十万上百万的数据，那么你的 cache 策略是什么？
1、没看到 数组下标来排序 的代码
2、activeNum 上应有索引（普通索引即可）
3、你知道访问数据库和访问 cache 的区别吗？
将数据库的压力转嫁到 cache 就一定合适吗？
如果有有几十万上百万的数据，那么你的 cache 策略是什么？
activeNum 是数字型，用索引也有效吗？一直以为 索引只用在where作用的字段上，排序的字段也可以用索引吗
排序也可以用到索引，不然数据量很大，不适用索引，你数据库不是崩溃。
1、没看到 数组下标来排序 的代码
2、activeNum 上应有索引（普通索引即可）
3、你知道访问数据库和访问 cache 的区别吗？
将数据库的压力转嫁到 cache 就一定合适吗？
如果有有几十万上百万的数据，那么你的 cache 策略是什么？
目前 activeNum这个字段没有加索引。
EXPLAIN 你的查询指令
MySQL 会给你有益的建议！而不是自己想当然的说
EXPLAIN 你的查询指令
MySQL 会给你有益的建议！而不是自己想当然的说
用命令查出来貌似不能用索引，我现在想到的一个办法是，新建一个rank表把用户的id，排名根据数组取下标放到rank表里面，然后在新表里面加一个uid等于0的字段，排名那里放我写入进去的时间，每次来取排名的时候先取uid=0的时间，对比当前时间，如果大于30分钟，那么就重新去active表读取一次排名放到rank表里面。不知道这方法可行么？
possible_key 是可被使用的索引，由于你没有对 activeNum 做索引，自然就没有啦
于是 Extra 列就有了 filesort，表示用了一个临时文件来对 activeNum 进行排序
possible_key 是可被使用的索引，由于你没有对 activeNum 做索引，自然就没有啦
于是 Extra 列就有了 filesort，表示用了一个临时文件来对 activeNum 进行排序
好吧，我再捣鼓捣鼓，php在linux里面有没有区分是否线程安全呢？每个用户访问一次比如我写了一个DB调用数据库，是只引用一次，所有用户都用的这一个，还是每个人都是独立的呢？
每个人都是独立的
你可以试试 单例模式， 把结果存在静态变量中试试
如果查询的量非常大，而数据又不是实时的可以做缓存来处理.但是如果数据又要是实时的 我觉得先找出瓶颈在什么地方，普通的索引等优化这些都是基础。
谢谢大家，用临时表做缓存解决了。