小弟做一个门户的新闻页，这个新闻页需求有一个“相关文章”，就是用标题模糊搜索相关文章后显示前台，好多网站都有这样的区域.
问题来了:
这个数据量比较大，大概100万左右，实时搜索的话那数据库压力太大，而且前台显示比较慢.
第二就是缓存，缓存后访问量高的话再多的内存也爆了，有没有更好的办法呢？小弟技术有限，特来请教。
问题来了:
这个数据量比较大，大概100万左右，实时搜索的话那数据库压力太大，而且前台显示比较慢.
第二就是缓存，缓存后访问量高的话再多的内存也爆了，有没有更好的办法呢？小弟技术有限，特来请教。
先分词,按照相同词出现的频率,比较相似度
提供后台运行的服务，异步延迟加载
这类搜索不需要即刻显示，但是需要即刻开始。比如一个文章的相关文章，你需要1分钟才计算出来，那么就是这一分钟之内的文章页面内可能在这个地方显示为空的。但是第一次访问以后1分钟之后，再访问这个文章页面，就有相关文章内容了。我不知道你说的“缓存”是什么意思。有些人想当然地说缓存就是把一个数据库表放到内存中，我对这种东西毫不以为然。缓存就是这样，key=“查询内容id为123456的文章的相关文章”，比如结果是6个文章id，进行一次缓存就是把这个key跟6个id匹配起来放入Cache，而缓存其它文章的相关文章查询结果则需要另外进行一次缓存，这跟把什么数据库表放入内存作为一次缓存有什么关系？
这种方法可行是可行，但是鸭梨还是不小啊，毕竟是like出来的。而且是有多少个词就要搜索多少次。
抛开缓存，我问你你能保证页面上立刻打开并且有相关文章列表吗？你把两个问题给我纠结在一起，本来是应该既要做到A又要做到B的，你便说“A不成，因为不是B；B不成，因为不是A”，这中两头堵的方式还是别做开发做测试算了。
ACCESS用instr()
sql用charindex()
你对缓存还是把数据表中的数据全都丢到内存里的思路，这种方式怎么可能用起来缓存？假设一个业务逻辑需求：“返回某个文章id的相关文章id列表”，我们就把它的结果缓存5分钟，设置absoluteExpiration和slidingExpiration参数都为5分钟，也就是超过5分钟都不被重复访问的内容根本没有价值缓存。那么反过来说，你可以算算你的网站5分钟内经常被重复访问的文章才有多少个？我说的1小时才用1M缓存，你认为5分钟会用多少？什么叫做“缓存24小时”？就是说24小时才有一次重复访问的文章，你也觉得有必要占用内存来缓存！这完全是我不以为然的那种对待缓存的观念。那么你说的那种缓存，是我觉得毫无意义的做法。
related_article_id
updated_at如果是新闻类网站，相关文章的数量不会太多，一般最新十条二十条就可以，即使你有100万记录，top加where，也不会怎么吃力。数据可以一天更新一次，updated_at 字段可以用来帮助选择更新时机，而就不用一次更新整个表。
给新闻表（News）设置一个主键，int 自增的，就叫做NewsID吧，这个要聚集索引。然后呢有一个标题的字段 NewsTitle。你可以放心大胆的用下面这条SQL获取“相关文章”：select top 5 NewsTitile ,[其他需要的字段，不需要的不要写] from News where NewsTitle like '%key%' order by NewsID desc不管是10万条记录还是100万条记录，保证1秒内得到结果。不信的话，你可以自己试一试。