200百万数据怎样建索引

200百万数据怎样建索引 在线等
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’，又不行了。
[解决办法]

引用:

使计划从table scan变为seek sacn+Key Lookup  怎样做到

打错了，是INDEX sacn（NAME） +Key Lookup  
[解决办法]
前面的都说到了，全文索引或是函数索引，但对于你这种查询来讲可能并没有太大提升。
另外，还可以考虑从表结构上来考虑。
引用一位大师的话——《SQL语言艺术》第66页的总结。
函数索引的使用通常暗示设计存在问题，数据模型甚至连基本的数据原子性问题都没有解决。
所以，我想，你把“姓名”字段分拆为“姓”和“名”并建立索引，对问题会有一定的改善，但是是否可以分拆得更细，看你的业务来做权衡了。
[解决办法]

引用:

前面的都说到了，全文索引或是函数索引，但对于你这种查询来讲可能并没有太大提升。
另外，还可以考虑从表结构上来考虑。
引用一位大师的话——《SQL语言艺术》第66页的总结。
函数索引的使用通常暗示设计存在问题，数据模型甚至连基本的数据原子性问题都没有解决。
所以，我想，你把“姓名”字段分拆为“姓”和“名”并建立索引，对问题会有一定的改善，但是是否可以分拆得更细，看你的业务来做权衡了。

除非不考虑数据的准确性，否则暂且不论怎么进行分词，就基础表跟全文索引之间的同步就有时差的，它不是在一个transaction里进行的。

[解决办法]
这种情况下不用建立索引的，即使建立索引也是没有用的。
[解决办法]
除非不考虑数据的准确性，否则暂且不论怎么进行分词，就基础表跟全文索引之间的同步就有时差的，它不是在一个transaction里进行的。
全文索引了解不是太多，分词就更没有接触了，这方面不是太明白，一会去查下资料。

我上面的意思是说，更改表的结构，把Name拆分成firstName和lastName的组合。那么，对于某些查询来说，如：查找所有姓张的用户的姓名，语句可以由原来的name like ‘张%’，变成lastName = '张'的形式。
再举个例子，在存储地址时，可能你会存储“重庆市沙坪坝区沙中路88号”，那么我们在查询时，可能需要使用like这样的语句来查找，但是like里具体要查什么呢？是不是会有，查询我们现在的地址中包含某个字的这种需求呢？我想不是，更多的是固定的name like ‘%重庆%’或者是name like ‘%沙坪坝%’吧？那么，这时候，分拆成省、市、区的存储方式应该是能解决问题的。
通过仔细分析业务需求，调整表的结构以适应，这样一个思路。
[解决办法]
这种情况最好借助其他的搜索引擎技术，或者SQL Server自己的全文索引也可以，只是SQL Server的全文索引对中文支持的不很非常理想。

楼主使用Java，那么可以考虑开源的Apache Lucene，是一款基于Java的全文搜索引擎。

查看更多 下一篇