淡sqlserver对like '%关键词%' 处理时的索引利用问题

概述说法一：百分号%通配符前置会让SQL查询不走索引，改走全表扫描。这种说法很流行 结论是错误的 事实上这种说法不太准确 通配符%前置会让SQL查找索引时效率极速下降，但在大多数情况下还是会走索引（不需要全文索引，只要建一个普通的索引就可以了）   CREATE NONCLUSTERED INDEX [Ix_索引名] ON [dbo].[wkf_表名]  (  [db_title]  ASC ) 此时

说法一：百分号%通配符前置会让SQL查询不走索引，改走全表扫描。这种说法很流行

结论是错误的

事实上这种说法不太准确 通配符%前置会让sql查找索引时效率极速下降，但在大多数情况下还是会走索引（不需要全文索引，只要建一个普通的索引就可以了）

 

CREATE NONCLUSTERED INDEX [Ix_索引名] ON [dbo].[wkf_表名] 
(
 [db_Title]  ASC
)

此时执行

SELECT top 10 [db_ID],[db_Summary],[db_AddDate],[db_Title]  FROM [库名].[dbo].[wkf_database]   where [db_Title]like ‘%dba%‘  order by 1 desc
 
查询计划显示得很清楚

对比加索引之前：

说一个例外，复杂查询查询优化器可能会抛弃索引改走全表扫描。这不仅是liKE ‘%关键词%‘ 时会这样，跟查询复杂度有关

 

 

说法二：百分号%通配符前置会让SQL查询走索引不如不走索引

这种说法非常片面，走索引比不走索引99%的情况下都会减少IO从而提高效率，但是：索引查找完的键匹配动作也是有一部分性能消耗的。像上面两张图所示，如果关键字很容易就匹配到了，全表扫描很快就找齐了数据，而索引扫描节省的时间不足以弥补键匹配动作所消耗时间的时候这种情况就发生了（大部分线上查询不存在这问题）这时候优化就变得诡异了。
处理方法:
1.不去管它，多出来的性能消耗不是很大。而且不同的关键词有不同的消耗，只是部分关键词存在此问题，可以忽略
2.更好的方法，如果条件允许建覆盖索引(又叫INCLUDE索引)。前题条件：a存储空间充足，b不显著影响DML *** 作，c覆盖的索引中没有大字段

CREATE NONCLUSTERED INDEX [Ix_索引名] ON [dbo].[wkf_表名] 
(
 [db_Title]  ASC
)
INCLUDE ( [db_ID],[db_AddDate])

此时执行查询计划如下，清爽多了吧

 

以上就是我现在能想到的sqlSERVER处理SELECT *  FROM tablename liKE  ‘%关键词%‘

 

总结：

 

1.使用模糊查询最好使用后置，前置会大大降低效率。

 

select * from T_OMS_EMPLOYEE_BASEINFOR where usernameCn like ‘%肖%‘

2.使用全文检索，效率远远大于like

总结

以上是内存溢出为你收集整理的淡sqlserver对like '%关键词%' 处理时的索引利用问题全部内容，希望文章能够帮你解决淡sqlserver对like '%关键词%' 处理时的索引利用问题所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。