mysql5下大数据量查询优化的问题

回nihongye ：是用manager和createtime的索引没错。去掉order by的话，加上limit也是卡死

回Lucas Lee ：有加limit的。顶楼的我只是说即使加入时间条件，也会在大概20w以内的数据进行排序。


但今天回来再测试发现查询不会卡死进程，只是稍有延迟。不知道是不是因为昨天在测试前进行大量的数据导入所致。

没有orderby加上limit，按理来说，只会出现很少的磁盘读了。不清楚为什么出现你说的现象。
另外用mysqladmin extended-status检查
Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests的比例是否小于1/100.

Innodb_buffer_pool_reads          | 27193
Innodb_buffer_pool_read_requests  | 1270213

现在又出现这个问题了。

from blog, user where blog.userID=user.id and blog.manager=2  and blog.createTime <=1218613810 and blog.createTime >=1218009010 and blog.title like '随%'
order by blog.createtime desc  limit 0,20

耗时21多s

你对title,like啊。explain 出来什么？

(1)不建议做联合索引,建议分别做索引
(2)不知道你为啥要用内链接,从你的业务需求上貌似没这种必要,可以考虑用外连接.
(3)程序的事务处理是否有合理

nihongye ：explain的结果也是使用manager上的联合索引。毕竟title没有做索引。

weishuwei ：
原来就是单独索引的，但速度更慢。

内联结会使结果数据相对准确一些。

那就是了，20万数据做like，开销很大。
你可以考虑跟title做联合索引,时间跟文本的联合索引很占空间 ; 或是在title做独立索引，并指定使用title上的索引.总之保证尽可能的少读取数据。
explain的结果rows列列出了需要验证的记录数，每一行的记录数相乘是总的记录数。

manager只有3个值, 做index没有效果, 反而会降低性能

目前能想到的最好方法是在blog表冗余一个manager字段,  这样的话就不用join, 直接查询blog表就可以.