百万条数据的库,如果'%我晕%' 的条数很多的话以下SQL的效率很高,反之则效率降低
SELECT TOP 10 *
from BL_Topic 
where BBSTitle like '%我晕%' 
order by LastReplyTime 
百万条数据的库,如果'%我晕%' 的条数较少的话以下SQL的效率很高,反之则效率降低
SELECT TOP 10 *
from BL_Topic 
where Contains((BBSTitle,[Content]),'我晕') 
order by LastReplyTime 效率始终很高,但无法实现对应的功能,比如排序,分页
SELECT TOP 10 *
from BL_Topic 
where Contains((BBSTitle,[Content]),'我晕') 问题在于使用全文索引的时候我使用ORDER BY会导致数据库先索引所有的数据然后再根据ORDER BY 取TOP的条数,而不象使用LIKE 先根据ORDER BY排序,然后取得对应的TOP的条数.
请教如何提升第二段SQL的效率?

解决方案 »

  1.   

    SELECT TOP 10 *
    from BL_Topic 
    where Contains((BBSTitle,[Content]),'我晕') 
    这个的效率就很高,在数百万条数据库中做的实验,而
    SELECT count(*)
    from BL_Topic 
    where Contains((BBSTitle,[Content]),'我晕') 
    的结果也是百万级的因为TOP 10 所以就只取了前10条数据,问题在于加了ORDER BY 以后就先取全部数据再来排序匹配前10条了
      

  2.   

    SELECT TOP 10 *
    from BL_EvaLuate 
    where Contains((BBSTitle,[Content]),'天气') 我在数据库中查询的结果为
    TopicID      BBSTitle                  Content   
    10118        天气sadfasf天气           天气
    10119        天气                      天气
    10120        天气fdasffsa天气          天气fdsf天气fdsf天气天气天气天气天气基本可以得知全文索引的排序结果是根据关联的唯一索引TopicID 来排序的,请问有没有办法使这个排序变成倒序.而不影响效率.
      

  3.   

    如果按你的说法效率没问题的话,那么加一个
    order by LastReplyTime
    这样子,其实也不会影响效率。比如你用原本的方法
    create view aa
    SELECT TOP 10 *
    from BL_EvaLuate 
    where Contains((BBSTitle,[Content]),'天气') 
    做一个视图然后用另一个视图对其进行
    order by LastReplyTime 
    操作,当然对效率损失及小。所以把order by LastReplyTime 
    放在原来的语句中:
    SELECT TOP 10 *
    from BL_EvaLuate 
    where Contains((BBSTitle,[Content]),'天气') 
    order by LastReplyTime
    也是一样的。但我仍然觉得做全文索引对于百万数据效率不高。如果你真的做过测试你的效率没问题,那我也就没什么说的了。
    有其它的解决方案也就不重要了。
      

  4.   

    SELECT TOP 10 *
    from BL_EvaLuate 
    where Contains((BBSTitle,[Content]),'天气') 
    这样子数据库只会取全文索引的前十条数据,效率当然高
    而增加order by LastReplyTime 后数据库就会取得所有符合条件的数据然后再来排序取前10条,效率当然就....
      

  5.   

    在BBSTitle的字段上建索引可以提高查詢速度