111,112
社区成员
发帖
与我相关
我的任务
分享大数据量模糊查询速度如何优化?
假设有表info结构如:
name(nvarchar(100)),content(nvarchar(4000))
就比如说新闻内容检索(如 name like '%ss%' 或者 content like '%ss%')，假设数据量达到100W条以上的时候，对于模糊查询的速度需几秒钟，如果数据量达到300--500W以上时，查询速度可能会达到10--20秒或更高
对于这样的查询，大家有什么好的解决方案吗?
name(nvarchar(100)),content(nvarchar(4000))
就比如说新闻内容检索(如 name like '%ss%' 或者 content like '%ss%')，假设数据量达到100W条以上的时候，对于模糊查询的速度需几秒钟，如果数据量达到300--500W以上时，查询速度可能会达到10--20秒或更高
对于这样的查询，大家有什么好的解决方案吗?
...全文
请发表友善的回复…
发表回复
handthing 2012-01-12
- 打赏
- 举报
3000W数据，SQL 2008，服务器配置很高，用模糊 查找like '%...%'
要8秒，CPU时间30多秒，去掉前面的一个%，几百毫秒。
考虑用全文，仅管搜索结果可能有点偏差。
还有一个方法就是分区表，多加几块存储，提升IO,但CPU降不下来，也是个麻烦事，确实是SQL的极限了。
要8秒，CPU时间30多秒，去掉前面的一个%，几百毫秒。
考虑用全文，仅管搜索结果可能有点偏差。
还有一个方法就是分区表，多加几块存储，提升IO,但CPU降不下来，也是个麻烦事，确实是SQL的极限了。
使我做你和平之子 2010-06-27
- 打赏
- 举报
用全文搜索，其实基本思路和楼主在45楼说的差不多，但是sql server的全文搜索，或者windows search,或者Lucene，都是比较成熟的产品，肯定比自己闭门造车做出来的强。分词，特别是中文分词，是很有技术含量的东西，需要计算语言学的知识，大量的统计数据，自己不好搞。英文的分词虽然简单一些，但是英文里一个词有不同的形式，比如动词有原形，过去式，过去分词等形式，这个处理起来同样不是那么简单的。sql server里的全文搜索对此提供了支持，比如查see,能把saw, seeing都查出来。
maje 2010-06-27
- 打赏
- 举报
软件：加索引，如果该表结构平凡变动，整个表重建一下。
做表分区，缩小查找范围
硬件：升级服务器，有这么多数据的应该不是小的应用，应该买个好点的服务器。
做表分区，缩小查找范围
硬件：升级服务器，有这么多数据的应该不是小的应用，应该买个好点的服务器。
zhgroup 2010-06-27
- 打赏
- 举报
对于LIKE %%这种查询，索引是没用的，只能通过其它方法
xk1126 2010-06-27
- 打赏
- 举报
建索引加服务器
zhgroup 2010-06-27
- 打赏
- 举报
44楼说的也是我最近想到的方案
就是对大文本进行分词处理，把获得的分词写入一个新表（每个关键词一个表），然后再加一个与关键词表相对应的关系表（即把关键词与具体信息建立关系），这样在查询时先查询关键词，如果有关键词，则从关键词关系中读出与该关键词相关联的具体数据信息
就是对大文本进行分词处理，把获得的分词写入一个新表（每个关键词一个表），然后再加一个与关键词表相对应的关系表（即把关键词与具体信息建立关系），这样在查询时先查询关键词，如果有关键词，则从关键词关系中读出与该关键词相关联的具体数据信息
whb147 2010-06-27
- 打赏
- 举报
有一种办法就是用空间换速度
分词
把content(nvarchar(4000)中内容拆分开来，然后分开存储
ID (int),keyword(varchar(100))
把索引做在keyword上，然后每次查询根据id去找原来的那个表里的id,就能把文章找出来了。
这么作的坏处就是空间要很大
坏处就是，只适合关键字查询
分词
把content(nvarchar(4000)中内容拆分开来，然后分开存储
ID (int),keyword(varchar(100))
把索引做在keyword上，然后每次查询根据id去找原来的那个表里的id,就能把文章找出来了。
这么作的坏处就是空间要很大
坏处就是，只适合关键字查询
huwei12345 2010-06-27
- 打赏
- 举报
like 必定扫全表，没办法
足球中国 2010-06-27
- 打赏
- 举报
[Quote=引用楼主 zhgroup 的回复:]
假设有表info结构如:
name(nvarchar(100)),content(nvarchar(4000))
就比如说新闻内容检索(如 name like '%ss%' 或者 content like '%ss%')，假设数据量达到100W条以上的时候，对于模糊查询的速度需几秒钟，如果数据量达到300--500W以上时，查询速度可能会达到10--20秒或更高
对于这样的查询，大家有什……
[/Quote]楼主的机子不错啊。多弄几个关键字好些。这样查询估计是要不的。就是no lock不锁表。也会造成io的大量读写。一个机子还好说再多个机子。恐怕就受不了了。
假设有表info结构如:
name(nvarchar(100)),content(nvarchar(4000))
就比如说新闻内容检索(如 name like '%ss%' 或者 content like '%ss%')，假设数据量达到100W条以上的时候，对于模糊查询的速度需几秒钟，如果数据量达到300--500W以上时，查询速度可能会达到10--20秒或更高
对于这样的查询，大家有什……
[/Quote]楼主的机子不错啊。多弄几个关键字好些。这样查询估计是要不的。就是no lock不锁表。也会造成io的大量读写。一个机子还好说再多个机子。恐怕就受不了了。
gohappy2008 2010-06-27
- 打赏
- 举报
用 “存储过程” 或者 “索引”
zhgroup 2010-06-26
- 打赏
- 举报
先查出一部分也是有问题，因为数据量在那摆着呢
我觉得还是应该从数据库的存储结构上去考虑
我觉得还是应该从数据库的存储结构上去考虑
winner2050 2010-06-26
- 打赏
- 举报
除了建立全文索引或者Lucene.net 索引没有别的办法了。
大字段查询速度肯定慢，就像查字典，没有通过索引而一页一页一字一词的对比，速度能不慢？
有了索引就像用拼音查字法、部首查字法，速度就快多了。
大字段查询速度肯定慢，就像查字典，没有通过索引而一页一页一字一词的对比，速度能不慢？
有了索引就像用拼音查字法、部首查字法，速度就快多了。
SL007315 2010-06-26
- 打赏
- 举报
1、虽然几十W条记录。但是你模糊查找一般不会列出说有符合条件的记录吧？使用存储过程（分页处理），这种代码在网上有很多。
2、从物理实现。这个楼上不少人都讲过原理：用负载均衡,把一个大表争成几个小表。或是使用分布式。
2、从物理实现。这个楼上不少人都讲过原理：用负载均衡,把一个大表争成几个小表。或是使用分布式。
捷哥1999 2010-06-26
- 打赏
- 举报
个人感觉，你要搜索的内容，不能做索引，所以跑不掉要全表扫描，这在算法上没有优化的余地了，所以只能从IO上下功夫，做硬盘RAID和分区处理。
herryfanghe21 2010-06-26
- 打赏
- 举报
海量数据要建索引
zakumiwb 2010-06-26
- 打赏
- 举报
这个东西太难了吧
ToHai 2010-06-26
- 打赏
- 举报
学习了
mchaojie1 2010-06-26
- 打赏
- 举报
这个没办法的。建立索引不起作用的。只能全表扫描。
helei123a 2010-06-25
- 打赏
- 举报
存储过程
loveSoftandhxy 2010-06-25
- 打赏
- 举报
顶顶顶顶顶顶顶顶顶顶顶,考虑减少数据，分开查询，建立索引等，上面大家都说了。
加载更多回复（30）
