MySQL的范围查询:
$id_list = implode(',',$arr); $sql = "select name,id from user where id in ($id_list)";//可能还会left join连表 //如果$arr数组非常大会很慢,对这种查询如何优化?
光阴似箭催人老,日月如移越少年。
提供几个方案:
1) 如果内存足够用的话(这个表都没有特别大),可以使用mysql的memory engine,即把查询都放到内存里就行了。memory engine可以使用hash index。
2)使用memcache或者redis作为cache,相当于每次查询时都要multi_get一次,没有命中的再回mysql查,可以大大的降低mysql的in后面跟的数量。查询回来之后,再multi_set一次。如果memcache或者redis被sharding了,那么这个效率也没太高,因为要一个server query一部分。
3) 可以采用一些分布式key-value存储,比如在可以订阅或者follow种情形下,比如数据A修改了,那么把订阅A的全部人都异步的写到他们自己的一个inbox里面,那个inbox每次只要O(1)的get就OK了。在一些大V很多的地方(少数用户的follower特别多),会把一堆followers最多的人数据单拿出来cache好用类似in的方法查询,剩下的少的newsfeed直接塞到inbox里,这一在存储和时间上折中一下。
我曾经目睹过csdn的in,那一大长窜子in数字,我都被吓尿了。虽然我不知道这个怎么优化,但我知道一般需要这个的最好考虑中间加上一层高速cache,或者干脆将这些I/O全部放到redis中,定期写入到数据库。然后,等大神怎么回答这个问题。
提供几个方案:
1) 如果内存足够用的话(这个表都没有特别大),可以使用mysql的memory engine,即把查询都放到内存里就行了。memory engine可以使用hash index。
2)使用memcache或者redis作为cache,相当于每次查询时都要multi_get一次,没有命中的再回mysql查,可以大大的降低mysql的in后面跟的数量。查询回来之后,再multi_set一次。如果memcache或者redis被sharding了,那么这个效率也没太高,因为要一个server query一部分。
3) 可以采用一些分布式key-value存储,比如在可以订阅或者follow种情形下,比如数据A修改了,那么把订阅A的全部人都异步的写到他们自己的一个inbox里面,那个inbox每次只要O(1)的get就OK了。在一些大V很多的地方(少数用户的follower特别多),会把一堆followers最多的人数据单拿出来cache好用类似in的方法查询,剩下的少的newsfeed直接塞到inbox里,这一在存储和时间上折中一下。
我曾经目睹过csdn的in,那一大长窜子in数字,我都被吓尿了。
虽然我不知道这个怎么优化,但我知道一般需要这个的最好考虑中间加上一层高速cache,或者干脆将这些I/O全部放到redis中,定期写入到数据库。
然后,等大神怎么回答这个问题。