name 查询，name 是唯一的
------解决方案--------------------
如果没有where条件，建不建都一样，如果有where条件，而且是name，可以考虑键聚集索引。
------解决方案--------------------
表的定义是什么，具体的T-SQL 查询语句是什么？
------解决方案--------------------
你这写法就不用建索引了，建了也没用
------解决方案--------------------
如果你用的是.net,推荐用doHubble技术,搜索速度飞快
http://www.cnblogs.com/eaglet/archive/2010/04/07/1706305.html
------解决方案--------------------
建议对name建非聚集索引，在结果集不大的情况下能享受到非聚集索引带来的性能的提升。
------解决方案--------------------
name like '%xxx%'试一下改成charindex(name,'xxx')>1或者用全文索引
------解决方案--------------------
我很遗憾的告诉你，name like '%xxx%'目前没有很好的解决方案，现在的解决方案只有两种，但都有缺陷。
1，string summary技术
也就是我上面说的对name建非聚集索引，使计划从table scan变为seek sacn+Key Lookup, 但这种技术只有在返回的结果集不大，并且name的大小占整个表比率不大的情况才有比较好的性能提升。
2，对计算列建索引
比如，先建立计算列charindex('xxx',name)假设叫CCOM ，然后再对CCOM建索引，然后把name like '%xxx%'改为CCOM >0
除了上面2种其他应该没有了其他的方法了，包括全文索引在内。
------解决方案--------------------
上面第二种方法的缺陷就是依赖于具体的值'xxx'，如果把'xxx'改为‘YYY’，又不行了。
------解决方案--------------------
打错了，是INDEX sacn（NAME） +Key Lookup
------解决方案--------------------
前面的都说到了，全文索引或是函数索引，但对于你这种查询来讲可能并没有太大提升。
另外，还可以考虑从表结构上来考虑。
引用一位大师的话——《SQL语言艺术》第66页的总结。
函数索引的使用通常暗示设计存在问题，数据模型甚至连基本的数据原子性问题都没有解决。
所以，我想，你把“姓名”字段分拆为“姓”和“名”并建立索引，对问题会有一定的改善，但是是否可以分拆得更细，看你的业务来做权衡了。
------解决方案--------------------
除非不考虑数据的准确性，否则暂且不论怎么进行分词，就基础表跟全文索引之间的同步就有时差的，它不是在一个transaction里进行的。