有个查询sql 需要优化

langwang0070

恩，like确实是慢的很

in 和 or的差别不大

现在对like真没什么好办法

对了，我还准备对有dateline的 sql 强制执行dateline索引

如果去掉subject这个条件，返回的结果还真大啊

看来要结合limit才行

[ 本帖最后由 langwang0070 于 2009-11-6 10:44 编辑 ]

ruochen

in 和 or的差别不大


但是加上like后，区别你测试了吗？

langwang0070

不加like前 返回的数据量已经相当大了，很耗时；加上like 返回的数据量会大大减少

不过性能瓶颈确实在like上

光用sql优化好像已经不能满足了


说明：对于这个SQL效率低的原因在于数据量太大，为了取得高的效率，在程序方面将时间范围缩小为一个月这样就ok了。

[ 本帖最后由 langwang0070 于 2009-11-6 15:44 编辑 ]

cenalulu

总结下来就是：能用到索引的地方，过滤量不大，导致不能用到索引的地方产生了性能问题。

cg111

从下面的查询语句看

SELECT pid FROM cdb_posts WHERE dateline >= 1226036800  AND dateline <= 1257659199 AND invisible IN (-5,-2,0) AND subject != '' AND subject LIKE '%帖子%'

实际上mysql只对dateline使用了索引,其他的应该只是作为输出的过滤，请注意，使用索引和输出过滤的区别。
使用索引时候，只对索引进行扫描，根据索引从数据表取数。
而使用输出过滤是从取出的数中根据过滤条件，将不符合条件的数据不输出而已。
而索引条件的输出有多少？
1257659199-1226036800=31622399
是300多万，和你的数据量基本相同，所以基本上相当于全表扫描了（当然，可能还是少扫描了部分）根据这样的使用情况，这个索引使用的不合理。
如果invisible in (-5,-2,0)可以减少很多的表扫描的话,建议还是用force index (invisible)强制使用invisible索引来试试.
这种优化问题,修改输出过滤条件不会带来任何性能提升的,因为不会减少表扫描.只有在减少表扫描方面优化,才能提高性能

Coolriver

这个问题，你可以请教一下CU的老范，大CU贴子在300W左右时是怎么实现的搜索。
我以前把一个客户把Discuz的搜索改成用Sphinx实现，效果也挺好的。从后台的搜索有1个小时有时都出不来结果，到后来，基本可以瞬时出来结果。但用Sphinx也有一系列的问题。

langwang0070

大家说的都很有道理。对于这个sql语句，除了缩小时间范围能对SQL本身进行优化，其他的只能考虑sql以外的了。

上面那个引擎听说很好的，不过本人不是dba，还需要专人来搞了。

ruochen

原帖由 Coolriver 于 2009-11-8 11:01 发表
这个问题，你可以请教一下CU的老范，大CU贴子在300W左右时是怎么实现的搜索。
我以前把一个客户把Discuz的搜索改成用Sphinx实现，效果也挺好的。从后台的搜索有1个小时有时都出不来结果，到后来，基本可以瞬时 ...

这个是开源的

http://www.coreseek.com/
这个是CU使用的

[ 本帖最后由 ruochen 于 2009-11-10 12:30 编辑 ]

la19850302

dateline条件走索引不会有问题,如果慢,那是你数据确实这么分布的,也没办法事

如楼上,那个in -> or 是基础优化了

like嘛,经常性的瓶颈,业务如果确实需要,也没办法

所以,从语句本身来看,可以优化的地方不多,可以使用分区表或者分表的方式,重新组织数据

300w的数据量,dateline又没起到啥作用,你再来个like,一般机器都会慢

我们这边的bbs单表最大也不能超过500w数据量,采用了分表再分区形式,至于那个like,业务那边需要,我们这边基本无解,是搜索部门的事情了

la19850302

如16楼的

周五听了下Sphinx的培训课程,有支撑mysql的引擎,也支持中文,在文本收索方面很优秀

我们这边的搜索业务正是使用的这个语言,效果很好,然后那些人很得意