這天老鳥火急火燎的沖到菜鳥座位：“還記得你在雲栖社群發表的一篇名為‘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語句的性能問題吧。