mysql limit执行很慢

kidbei 发布于 2013/09/12 12:56
阅读 1K+
收藏 0

用Ebean生成分页查询语句

select t0.C_ID c0, t0.C_TITLE c1, t0.C_OLD_URL c2, t0.C_CONTENT c3, t0.C_TEXT c4, t0.C_AUTHOR c5, t0.C_BLOG_WEB c6, t0.C_BLOGTYPE c7, t0.C_SAVE_DATE c8 
from t_article t0 
order by t0.C_SAVE_DATE 
limit 11 offset 4920

执行到offset 4000多的时候就非常慢了,一条语句要十几秒

这是为嘛尼?才7000多条记录啊

加载中
0
tsl0922
tsl0922
SQL语句也不是很复杂,才7000多条记录,不至于这么慢吧?加索引了吗?explain下看看是不是全表扫描,用到索引了没有。
kidbei
kidbei
有俩longtext字段
0
你要爪子
你要爪子
EXPLAIN 贴下看看
kidbei
kidbei
图在下面...
0
mark35
mark35

t0.C_SAVE_DATE 字段上有没有索引?

虽然mysql在大分页下性能比较差,但也不至于4000多记录就这样

0
deller
deller
C_SAVE_DATE 如果可以,换成 int 类型存储再加一个索引。
0
鱼龙帅
索引没用的,几乎是全表扫描!试试对排序的字段加索引看看!
0
你要爪子
你要爪子
想不通为何这么不慢。换个方式 id> 4920  limit 11 看看能不能快点
kidbei
kidbei
查询结果有两个Longtext字段,只查一个就快了。另外,ID是UUID,不是子增长
0
huanlin08
huanlin08
肿么会,mysql数据库其实性能很高的,前提是必须要建立索引,索引还必须是合理。我测试过几十万的数据,没索引前查询要等4秒左右,有索引后查询都是一闪就出来了。用不到一秒。这就是差距啊
0
evangelist64
evangelist64

才几千条记录又不是几千万,没索引关系不大,而且运算也不复杂就一个order by,索引就在排序时起点作用,还不知道那个C_SAVE_DATE是什么玩意适不适合做索引

我随便猜一下:

1.Data Length太大了,那些longtext字段查出来太吃内存。

2.用于order by的字段太长,而且相似度高不易区分,比较起来很慢。

3.机器问题,比如硬件快坏掉了,或者本身就是个小霸王。

evangelist64
evangelist64
回复 @kidbei : 那还是把数据分割成几部分逐个测试吧
kidbei
kidbei
回复 @evangelist64 : 可是再大也不会超过10M啊,10M的东西很小了,都是文本。。。搞不懂....
evangelist64
evangelist64
回复 @kidbei : 简单考虑,是不是因为那两个字段前面的数据都比较短,后面存进去的都比较长。
kidbei
kidbei
你猜对了很大一部分,longtext有两个字段,如果去掉一个字段速度就快了,但是不理解的地方是为什么offset比较小的时候都是秒查,而越到后面就越慢了呢? sC_SAVE_DATE是datetime字段
0
八宝旗
八宝旗
查询前,把session的tmp_table_size值设的大点试试,如果中间结果(offset比较大,并且有大字段)超过tmp_table_size,则会将结果保存到磁盘临时的myisam表中,可以用profile看下具体在什么阶段比较耗时
返回顶部
顶部