31 个解决方案
#1
....这个怎么说....
看数据的可选择性...选择性高 就走索引...
看数据的可选择性...选择性高 就走索引...
#2
数据量有几百万呢，使用这样的语句，索引会失效的。
#3
使用like'%匹配的文字%',无法优化,因为索引起不到作用.
不过like'匹配的文字%',索引起作用.
#4
学习了！
#5
真的？
#6
假如该字段上有索引，并且查询的选择性足够高：
LIKE '匹配的文字%'，可以执行Index Seek，效率高。
LIKE '%匹配的文字%'，不能执行Index Seek，但可能执行Index Scan，而Index Scan是有可能比Table Scan效率高的。简单地说“索引起不到作用”，太武断了。
在不使用全文索引的情况下，后者的效率当然没有前者高。
然而如果业务上就是需要后一种查找，像LZ的需求：
1) 如果同时有其它限定条件，在其它限定条件上加索引。
2) 如果只有这一个条件，并且该字段长度不超过900字节，在这个字段上加索引。
3) 如果以上条件不满足，有需要提高查询效率，考虑全文索引。
LIKE '匹配的文字%'，可以执行Index Seek，效率高。
LIKE '%匹配的文字%'，不能执行Index Seek，但可能执行Index Scan，而Index Scan是有可能比Table Scan效率高的。简单地说“索引起不到作用”，太武断了。
在不使用全文索引的情况下，后者的效率当然没有前者高。
然而如果业务上就是需要后一种查找，像LZ的需求：
1) 如果同时有其它限定条件，在其它限定条件上加索引。
2) 如果只有这一个条件，并且该字段长度不超过900字节，在这个字段上加索引。
3) 如果以上条件不满足，有需要提高查询效率，考虑全文索引。
#7
有一定数据量的话，方法只有两个：
1、全文索引，这个不多说了。
2、实际也是全文索引的思想，只是自己来稿，就是增加关联的关键词表，把需要查询的数据表的每条数据的关键词单独存放，关键词可以建立索引，查询时关联查询。
1、全文索引，这个不多说了。
2、实际也是全文索引的思想，只是自己来稿，就是增加关联的关键词表，把需要查询的数据表的每条数据的关键词单独存放，关键词可以建立索引，查询时关联查询。
#8
全文索引
#9
真的
#10
2008自动优化了
#11
要不全文索引，试一下？！
#12
一般情况下几百条数据模糊查询可以用LIKE，但是超过几千上万条就建议用全文索引了！
#13
引用楼主 chxy148 的回复:
like'%匹配的文字%'，SQL Server 2008怎么优化？？请高手帮助解决，不胜感激！
使用like'%匹配的文字%',无法优化,因为索引起不到作用.
不过like'匹配的文字%',索引起作用.
这个是正确的
like'%匹配的文字%'，SQL Server 2008怎么优化？？请高手帮助解决，不胜感激！
使用like'%匹配的文字%',无法优化,因为索引起不到作用.
不过like'匹配的文字%',索引起作用.
这个是正确的
#14
要想快 方法只有一个 请使用=不要使用like 其实很多时候like查询出的数据提交给用户很多都是无用的 纯属浪费数据库资源而已
#15
mark.
#16
%匹配字符% 不行 用不到索引
还是全文索引吧
还是全文索引吧
#17
几百万的数据量用like没问题啊，我们系统都几千万的量了还可以like，只是慢点，这点可以和用户说清楚，
优化也快不了多少。想快就别用like
优化也快不了多少。想快就别用like
#18
学习！
#19
where col like '%parten%'--如果col上建立了Index，SQL Server也无法使用Index，但应该也不会Table Scan，可以Index Scan
where col like 'parten%'--如果col上建立了Index，SQL Server可以使用col上Index。理解方式如下：Mysql中有PreIndex(前缀索引)的机制，也就是说如果我的某个字段前面N个字符长度的唯一率达到了90%以上，那么我们的Index就可以在该字段的前面N个字符上。回到SQL Server中，它就可以使用左边的Parten来匹配索引。
#20
补充下，如果业务的确需要完全模糊匹配，即：where col like '%parten%'，建议使用其他的基于数据库的产品之一：组要的思路是将数据库的数据抓取出来->Build成Endeca或者Solr可以识别的Index->用户查询直接检索Index文件
1.endeca
2.solr
#21
假如该字段上有索引，并且查询的选择性足够高：
LIKE '匹配的文字%'，可以执行Index Seek，效率高。
LIKE '%匹配的文字%'，不能执行Index Seek，但可能执行Index Scan，而Index Scan是有可能比Table Scan效率高的。简单地说“索引起不到作用”，太武断了。
在不使用全文索引的情况下，后者的效率当然没有前者高。
然而如果业务上就是需要后一种查找，像LZ的需求：
1) 如果同时有其它限定条件，在其它限定条件上加索引。
2) 如果只有这一个条件，并且该字段长度不超过900字节，在这个字段上加索引。
3) 如果以上条件不满足，有需要提高查询效率，考虑全文索引。
LIKE '匹配的文字%'，可以执行Index Seek，效率高。
LIKE '%匹配的文字%'，不能执行Index Seek，但可能执行Index Scan，而Index Scan是有可能比Table Scan效率高的。简单地说“索引起不到作用”，太武断了。
在不使用全文索引的情况下，后者的效率当然没有前者高。
然而如果业务上就是需要后一种查找，像LZ的需求：
1) 如果同时有其它限定条件，在其它限定条件上加索引。
2) 如果只有这一个条件，并且该字段长度不超过900字节，在这个字段上加索引。
3) 如果以上条件不满足，有需要提高查询效率，考虑全文索引。
#22
来学习的
#23
学习学习
#24
学习了
哈哈
哈哈
#25
开启全文索引吧
#26
单位 姓名 职务 记分次数 合计分值 通报批评 警告 记过 记大过 降级 撤职 开除 停职 禁闭 辞退 警诫 诫免谈话 扣津贴
单位1 张三 科员 10 100 1 2 1 1
单位2 李四 科员 3 50 1 2 3
单位1 张三 科员 10 100 1 2 1 1
单位2 李四 科员 3 50 1 2 3
#27
放错地方！
#28
基本上是没有好的优化方式的，除非改变表结构，把parten单独放一个字段
#29
在索引上做任何行为的计算都会让索引失效！
#1
....这个怎么说....
看数据的可选择性...选择性高 就走索引...
看数据的可选择性...选择性高 就走索引...
#2
数据量有几百万呢，使用这样的语句，索引会失效的。
#3
使用like'%匹配的文字%',无法优化,因为索引起不到作用.
不过like'匹配的文字%',索引起作用.
#4
学习了！
#5
真的？
#6
假如该字段上有索引，并且查询的选择性足够高：
LIKE '匹配的文字%'，可以执行Index Seek，效率高。
LIKE '%匹配的文字%'，不能执行Index Seek，但可能执行Index Scan，而Index Scan是有可能比Table Scan效率高的。简单地说“索引起不到作用”，太武断了。
在不使用全文索引的情况下，后者的效率当然没有前者高。
然而如果业务上就是需要后一种查找，像LZ的需求：
1) 如果同时有其它限定条件，在其它限定条件上加索引。
2) 如果只有这一个条件，并且该字段长度不超过900字节，在这个字段上加索引。
3) 如果以上条件不满足，有需要提高查询效率，考虑全文索引。
LIKE '匹配的文字%'，可以执行Index Seek，效率高。
LIKE '%匹配的文字%'，不能执行Index Seek，但可能执行Index Scan，而Index Scan是有可能比Table Scan效率高的。简单地说“索引起不到作用”，太武断了。
在不使用全文索引的情况下，后者的效率当然没有前者高。
然而如果业务上就是需要后一种查找，像LZ的需求：
1) 如果同时有其它限定条件，在其它限定条件上加索引。
2) 如果只有这一个条件，并且该字段长度不超过900字节，在这个字段上加索引。
3) 如果以上条件不满足，有需要提高查询效率，考虑全文索引。
#7
有一定数据量的话，方法只有两个：
1、全文索引，这个不多说了。
2、实际也是全文索引的思想，只是自己来稿，就是增加关联的关键词表，把需要查询的数据表的每条数据的关键词单独存放，关键词可以建立索引，查询时关联查询。
1、全文索引，这个不多说了。
2、实际也是全文索引的思想，只是自己来稿，就是增加关联的关键词表，把需要查询的数据表的每条数据的关键词单独存放，关键词可以建立索引，查询时关联查询。
#8
全文索引
#9
真的
#10
2008自动优化了
#11
要不全文索引，试一下？！
#12
一般情况下几百条数据模糊查询可以用LIKE，但是超过几千上万条就建议用全文索引了！
#13
引用楼主 chxy148 的回复:
like'%匹配的文字%'，SQL Server 2008怎么优化？？请高手帮助解决，不胜感激！
使用like'%匹配的文字%',无法优化,因为索引起不到作用.
不过like'匹配的文字%',索引起作用.
这个是正确的
like'%匹配的文字%'，SQL Server 2008怎么优化？？请高手帮助解决，不胜感激！
使用like'%匹配的文字%',无法优化,因为索引起不到作用.
不过like'匹配的文字%',索引起作用.
这个是正确的
#14
要想快 方法只有一个 请使用=不要使用like 其实很多时候like查询出的数据提交给用户很多都是无用的 纯属浪费数据库资源而已
#15
mark.
#16
%匹配字符% 不行 用不到索引
还是全文索引吧
还是全文索引吧
#17
几百万的数据量用like没问题啊，我们系统都几千万的量了还可以like，只是慢点，这点可以和用户说清楚，
优化也快不了多少。想快就别用like
优化也快不了多少。想快就别用like
#18
学习！
#19
where col like '%parten%'--如果col上建立了Index，SQL Server也无法使用Index，但应该也不会Table Scan，可以Index Scan
where col like 'parten%'--如果col上建立了Index，SQL Server可以使用col上Index。理解方式如下：Mysql中有PreIndex(前缀索引)的机制，也就是说如果我的某个字段前面N个字符长度的唯一率达到了90%以上，那么我们的Index就可以在该字段的前面N个字符上。回到SQL Server中，它就可以使用左边的Parten来匹配索引。
#20
补充下，如果业务的确需要完全模糊匹配，即：where col like '%parten%'，建议使用其他的基于数据库的产品之一：组要的思路是将数据库的数据抓取出来->Build成Endeca或者Solr可以识别的Index->用户查询直接检索Index文件
1.endeca
2.solr
#21
假如该字段上有索引，并且查询的选择性足够高：
LIKE '匹配的文字%'，可以执行Index Seek，效率高。
LIKE '%匹配的文字%'，不能执行Index Seek，但可能执行Index Scan，而Index Scan是有可能比Table Scan效率高的。简单地说“索引起不到作用”，太武断了。
在不使用全文索引的情况下，后者的效率当然没有前者高。
然而如果业务上就是需要后一种查找，像LZ的需求：
1) 如果同时有其它限定条件，在其它限定条件上加索引。
2) 如果只有这一个条件，并且该字段长度不超过900字节，在这个字段上加索引。
3) 如果以上条件不满足，有需要提高查询效率，考虑全文索引。
LIKE '匹配的文字%'，可以执行Index Seek，效率高。
LIKE '%匹配的文字%'，不能执行Index Seek，但可能执行Index Scan，而Index Scan是有可能比Table Scan效率高的。简单地说“索引起不到作用”，太武断了。
在不使用全文索引的情况下，后者的效率当然没有前者高。
然而如果业务上就是需要后一种查找，像LZ的需求：
1) 如果同时有其它限定条件，在其它限定条件上加索引。
2) 如果只有这一个条件，并且该字段长度不超过900字节，在这个字段上加索引。
3) 如果以上条件不满足，有需要提高查询效率，考虑全文索引。
#22
来学习的
#23
学习学习
#24
学习了
哈哈
哈哈
#25
开启全文索引吧
#26
单位 姓名 职务 记分次数 合计分值 通报批评 警告 记过 记大过 降级 撤职 开除 停职 禁闭 辞退 警诫 诫免谈话 扣津贴
单位1 张三 科员 10 100 1 2 1 1
单位2 李四 科员 3 50 1 2 3
单位1 张三 科员 10 100 1 2 1 1
单位2 李四 科员 3 50 1 2 3
#27
放错地方！
#28
基本上是没有好的优化方式的，除非改变表结构，把parten单独放一个字段
#29
在索引上做任何行为的计算都会让索引失效！