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

我看问题关键是，为何要筛选出20万数据？

这样的需求应该用全文检索来做，用sql来做是很难优化的。

第一：如果该做innodb引擎的话，它的效率是没有myisam快

第二：如果索引正确的话，应该检查是否有锁死的事务(前提是innodb)，或者在insert时是否用了delay等

第三：检查mysql服务器配置参数设置

第四：最小时间段内也有9-20w的话就应该考虑用分页

第五： 在数据量大到一定级别的时候（如果每天都有3、4百万的数据），mysql本身的负载就成问题。如果初期考虑到这些的时候，请lz及时更换数据库吧。否则即使做集群，也会带来很大的问题

老兄，你真正在mysql下做过sql优化没有！

XD，你说呢？？有什么不妥的地方还是我没说清楚？

珍惜生命，远离like。

所有使用like的情况都考虑是否应该使用全文检索。

大部分普通需求下，使用现在的众多手段实现基本可用的全文检索，轻松简单。

严重同意。
尤其是楼主的情况，哪有title like 'xx%'的博客呀，凡是需要title like 'xx%'的情况的博客，都用全文检索实现的。不信你问问robin。
BTW：两个表数据量大的时候，即使不用like，join也会很慢，用冗余字段或者N+1提高性能吧。
再次BTW：N+1很多时候还是很快的，比如limit的情况。

如果像细致入微的进行分析问题的所在，需要做这样的事情。
　　explain来看看SQL执行的状态。 用show来看看索引的情况。 Handler_read_key 值高表示索引效果好，Handler_read_rnd_next值高表示索引低效。

　　用show processlist 查看当前运行状态。

要细致入微的查找，一般情况慢的原因大部分为i/o的写和读，还有就是分区是否是关键字段，好好的针对情况作处理。不要盲目的优化。可能事倍功半

1、貌似使用like后，该column的index就不起作用，所以你的title的index建了也是白建。倒不如来个全文索引。like简直是性能杀手。

2、比较倾向分两部查询。即先查blog，再查user。大表的连接查询还是比较耗时的。

恩，综上所述，看来应该稍为改一下程序，改为N+1就好了，不过目前尚未有时间去做这个大动作，所以暂无法回复大家修改后的效果，请见谅。

另外回复一部分朋友的问题：

blog就是博客表，user是用户表。user表有2000w用户很奇怪吗？

由于createTime目前不提供修改的功能，所以涉及时间排序的时候，我都用主键ID，而不是createTime。

另外对文本字段的like查找，使用like 'xx%'是可以使用索引的。但like '%xx%'则不行。