做一下分页查询优化。 如,你要获取最后50条数据: SELECT * FROM pre_forum_thread ORDER BY tid DESC LIMIT 0,50 就比你用这条快得多 SELECT * FROM pre_forum_thread ORDER BY tid LIMIT 2999950,50 你可以在页数大于一半或者三分之二的时候用上面一条,取决于你自己
explain 看下你的sql语句的情况
6楼写的很清楚,用limit,然后再用循环 i=0;j=50; SELECT * FROM pre_forum_thread ORDER BY tid DESC LIMIT i,j 如果他想看第51条数据 i=i+50;j=j+50 然后再select一遍就可以了 看后x页数据只需要 i=i+50*x;j=j+50*x 这个方法分页更好
如,你要获取最后50条数据:
SELECT * FROM pre_forum_thread ORDER BY tid DESC LIMIT 0,50
就比你用这条快得多
SELECT * FROM pre_forum_thread ORDER BY tid LIMIT 2999950,50
你可以在页数大于一半或者三分之二的时候用上面一条,取决于你自己
i=0;j=50;
SELECT * FROM pre_forum_thread ORDER BY tid DESC LIMIT i,j
如果他想看第51条数据
i=i+50;j=j+50
然后再select一遍就可以了
看后x页数据只需要
i=i+50*x;j=j+50*x
这个方法分页更好
表结构:索引这是常规的,然后可以分表,这是进阶的
查询方式上,要尽量缩小数据的范围,比如如果是按ID增大排序分页的,不是直接LIMIT 2999950,50,而是加个条件ID>前页最后一个记录ID,再取一页的数据就飞快了。
比如以前你搜索“我为什么这么帅”,模糊搜索,只出现“我为什么”四个字也算是搜索结果了,这样很耗资源,要“我为什么这么帅”都匹配上才算一条搜索结果。以前你在文章内容和标题中搜,现在最好在标题搜就行了,缩小范围。当然,如果有标签、文章简介之类更好。这样也能节省很多资源。还有就是做好文章搜索分类。比如“我为什么这么帅”,如果你的文章有分类的话,这一类搜索属于问询类,通过“为什么”这个关键字确定。然后直接转到问询类的文章,查询。这样可以大大减少范围了。当然还有就是通过时间段,比如以2年为一个时间段。查询的时候优选查询这2年,如果有结果,就放在第一页。等到用户点击第二页的时候,再查询往前2年那个时间段的文章数据。如果第一页的最近两年没有数据,就移到往前2年数据查询。这个方法也能节省大量资源。但是结果正确性不够好。这也无伤大雅,没有哪个搜索系统能一下把用户的需求理解得那么精确。
另外 discuz有潜在的缺陷,一般大网站,这类查询都是用C语言写,效率比php要高一个档次。
我只是捕捉到了SQL语句。直接去MYSQL里查询。如此的慢。感觉这种查询也是MYSQL的缺陷。
貌似改掉查询能有所改变。但也是2秒以上的查询
这种方式;应该在客户端cookie记录下上一页最后一条文章的id是多少,比如说是520
那么sql可以这样写:
where id > 520 limit 50
以前也遇到过了,简单的select * from tb limit $offset,$limit。后来解决的办法就是用between $id1 and $id2.不过根本就不切实际,大数据的时候MYSQL完全失灵了一样
以前也遇到过了,简单的select * from tb limit $offset,$limit。后来解决的办法就是用between $id1 and $id2.不过根本就不切实际,大数据的时候MYSQL完全失灵了一样
数据量大了,肯定就要从sql语句上或表结构上进行优化了
给字段增加索引肯定是必须的,任何数据库如果没有索引,性能再好,依旧会慢。
也可以用诸如sphinx的全文检索
再则,可以用数据缓存,如果没有实时性的要求,缓存也是提高速度的一部分
即将300万条数据分到多个表中去
2. 考虑使用缓存技术memcache 或者Nosql数据库