SQL Server FullText解决Like字句性能问题场景引入问题分析解决方法写在最后

这天老鸟火急火燎的冲到菜鸟座位：“还记得你在云栖社区发表的一篇名为‘sql server利用hashkey计算列解决宽字段查询的性能问题’的文章吗？被人踢馆啦，人家觉得你这个限制条件太苛刻，只能解决完全等于的问题条件下的性能问题，没有太大的现实意义。”

菜鸟烧脑的调动大脑的每一个细胞：“哦，你说的是这篇文章啊？”。

<a href="https://yq.aliyun.com/articles/61769?spm=5176.8091938.0.0.qjkg6n">sql server利用hashkey计算列解决宽字段查询的性能问题</a>

菜鸟反思着，的确，需要完全匹配这个条件限制太严格了，sql server有没有一种方法来代替like字句的功能而又可以大大提高查询效率的呢？因为，我们知道，like左模糊匹配是可以使用到索引，而右模糊和完全模糊匹配是完全无法使用到索引的。g哥告诉菜鸟有解决方法，用fulltext搜索啊。据说阿里云rds sql server 2008和ecs 版rds sql 2012都支持sql server的fulltext哦，对于使用阿里云rds sql server的用户真是个好消息。

来看我们的一个简单测试。

想要在超过900byte宽度的字段上创建索引，门都没有，sql server直接报错。

错误信息

非常有意思了，执行计划对比来看，like左匹配和完全模糊匹配均走是clustered index scan，相当于table scan；而estimaterows显示满足条件约为12440行，也暴露出sql server执行计划对like字句的评估并不准确，实际满足条件只有1行而已，所以导致最后的查询效率不高。但是，fulltext的执行计划中estimaterows显示只有1行，与实际情况相符合。

对比完执行计划，让我们来看看最后执行效率对比：

like左模糊匹配执行效率: logical reads 50185，说明io读非常高，这是clustered index scan导致的结果；cpu消耗47 ms，总的执行时间51ms。

like完全模糊匹配执行效率：和like左模糊匹配一样，logical reads 50185，也是io读非常高; cpu 更加离谱达到了4789ms，执行时间4919ms。

fulltext查询执行效率：logical reads仅仅只有5，所以最后cpu消耗为0ms，执行时间50ms。

从这个对比结果来看，fulltext完胜like字句，io读取大大降低，cpu消耗减少，效率得到了很大的提升。

完成上面的测试，菜鸟有了对老鸟和“踢馆者”合理的交代，那就是使用fulltext来解决like语句的性能问题吧。