none
关于全文索引:效率的变化,诡异! RRS feed

  • 问题

  • 环境:Win Server 2012+SQL Server 2012 SP1 on VMWare WorkStation 9

    表:Material2 (SID,SName,...十来个字段),PK:SID ,全文索引:SName,表空间30M左右,35万条记录,单用户访问

    测试结果(返回九百多条记录):

    上图,我查询所有字段,执行成本为0.137275,耗时一两百微秒

    下图,我查询一个字段SID,执行成本为2.98025,耗时一两百微秒

    而且两个执行计划的主要开销都在Clustered Index Seek

    按道理说,下图不需要Clustered Index Seek,因为全文索引是基于主键SID上的

    上图的查询成本有时是0.137275(这个成本可能性居少),有时是2.98025(这个成本可能性居多)

    神奇了一点点。。。(在SQL Server 2008 SP2环境里,两种情况执行成本总是2.98左右,耗时也是一两百微秒)


    Try SQL Server 2008 QQ:315054403 dgdba@hotmail.com

    2013年7月11日 9:08

全部回复

  • In this case, I'll double check with set 'statistics io' and 'statistics time'.
    2013年7月11日 13:06
  • 在SQL Server 2014 CTP1里测试结果:

    

    执行时间:总是200多微秒,没区别

    反复执行数次(至少超过五六次)

    当只执行Select .. Where Contains (或仅加前一行Select GetDate(),或仅加后一行Select GetDate()),执行成本为 1.57715,IO为Logical Reads: 1463

    当前后都加一条Select GetDate(),执行成本为0.0100246,IO为Logical Reads: 1425

    神奇的效果。。。。

    再之后即使前后都加一条Select GetDate(),执行成本又变为 1.57715,诡异!!


    Try SQL Server 2008 QQ:315054403 dgdba@hotmail.com

    2013年7月12日 1:39
  • 再次补充,既然全文基于SID的主键上,那么我仅查询返回SID,为什么还要Clustered Index Seek ???

    看来SQL SERVER全文应该改进一下


    Try SQL Server 2008 QQ:315054403 dgdba@hotmail.com

    2013年7月12日 1:41
  • Just curious, what's plan of 'select SName from Material2 where contains (SName, '...')'?
    2013年7月12日 2:11
  • select SName from Material2 where contains (SName, '...')

    or

    select SID from Material2 where contains (SName, '...')


    这下执行成本总是1.57715,不管前后是否加Select GetDate()

    全文索引根本没考虑Include情况,始终是Clustered Index Seek占了95%的开销

    在执行成本为0.0100246那个情况下,Clustered Index Seek占33%,参考上图


    Try SQL Server 2008 QQ:315054403 dgdba@hotmail.com

    2013年7月12日 2:58
  • 怎麽估计行数是39行,返回900多条数据估计行数是39行,统计信息没有更新??

    而且 PK:SID ,全文索引:SName

    成本应该第二个比第一个少

    2013年7月12日 13:45
  • 相同的sql语句 估计行数和执行成本不一样的??确实奇怪,做实验之前有没有重建索引,清空缓存,清空执行计划缓存??
    2013年7月12日 13:49
  • 你不是说PK:SID ,全文索引:SName 

    PK:SID 怎麽不是聚集索引查找呢?dgdba大侠??

    不知道我理解对不对,dgdba大侠的意思是既然有全文索引,为什麽还要使用聚集索引查找

    直接使用全文索引查找把sid查询出来是吧?

    我的理解:全文索引只是把你加了全文索引的那个字段添加到索引页,而其他字段还是保存

    在聚集索引里索引页,可能全文索引有指针指向聚集索引就像非聚集索引一样

    在全文索引里查找出数据之后再到聚集索引里读出其他字段的值

    • 已编辑 Steven.桦仔 2013年7月12日 13:58 增加补充回答
    2013年7月12日 13:50
  • TO华仔:

    一个单纯的实验环境,全新创建的表、主键、全文索引(所以不存在什么统计过期或无效的问题)

    全文基于主键,还跑去Clustered Seek,岂不多此一举

    按推理来说,全文做了抽词处理,那么Select SNAME 需要去Seek,那么Select SID 就不应该去Seek

    按常理来说,是应该先怀疑我的测试环境、方法,毕竟能质疑MS细节的人也不多,不过也还是有细节值得改进的


    Try SQL Server 2008 QQ:315054403 dgdba@hotmail.com

    2013年7月15日 0:52
  • 全文基于主键?你做过实验没有,是基于聚集索引还是非聚集索引?你看到索引页是否有存放全文索引里的列数据?

    还有 ,你select *  和 select sid 都包含 sid ,但是where 里没有sid,为什麽会查找,有些不明白

    2013年7月15日 1:22
  • 桦仔同学,建议你仔细看下每个贴子后,才作讨论或交流

    Try SQL Server 2008 QQ:315054403 dgdba@hotmail.com

    2013年7月15日 7:21
  • 环境:Win Server 2012+SQL Server 2012 SP1 on VMWare WorkStation 9

    表:Material2 (SID,SName,...十来个字段),PK:SID ,全文索引:SName,表空间30M左右,35万条记录,单用户访问

    测试结果(返回九百多条记录):

    上图,我查询所有字段,执行成本为0.137275,耗时一两百微秒

    下图,我查询一个字段SID,执行成本为2.98025,耗时一两百微秒

    而且两个执行计划的主要开销都在Clustered Index Seek

    按道理说,下图不需要Clustered Index Seek,因为全文索引是基于主键SID上的

    上图的查询成本有时是0.137275(这个成本可能性居少),有时是2.98025(这个成本可能性居多)

    神奇了一点点。。。(在SQL Server 2008 SP2环境里,两种情况执行成本总是2.98左右,耗时也是一两百微秒)


    Try SQL Server 2008 QQ:315054403 dgdba@hotmail.com

    dgdba大侠,你这里是不是写错了,因为全文索引是基于SName上的
    2013年7月15日 16:08
  • 桦仔同学,建议你仔细看下每个贴子后,才作讨论或交流

    Try SQL Server 2008 QQ:315054403 dgdba@hotmail.com

    dgdba老师我想进来学习一下,我觉得应该是非聚集索引查找才对

    如果你觉得我说的不对可以忽略我的

    2013年7月15日 16:10
  • 你可以把query plan在pk_materials2的output列出来?

    我怀疑在最后一个inner join的时候 两个plan有不同output


    If you think my suggestion is useful, please rate it as helpful.
    If it has helped you to resolve the problem, please Mark it as Answer.
    http://twitter.com/7Kn1ghts

    2013年7月18日 15:41