问题描述
有没有好的思路可以说下各位大神我觉得主要是这个缓存的key怎么处理还有分页一个严格的查询条件可能只是一个宽松条件的子集我想是如果以前缓存过这个宽松的条件我就不用再查数据库而是利用这个缓存再进一步的利用linq删选结果但是涉及到分页我那个宽松的条件可能只是缓存了部分数据不是全部的可是如果我把缓存规则定的太死比如完全按照条件和页数去匹配我又感觉命中率肯定不高。。。。
解决方案
解决方案二：
我觉得何时需要获取新数据，合适只是在内存中筛选，你应该是知道的，所以你就定义两种操作，如果需要新数据，你就分页取新数据，并把新数据合并到内存，需要过滤时，就只操作内存如果你的过滤都是基于全部数据的话，那你这缓存也就没意义了，第一次就需要把全部数据放到内存
解决方案三：
那像京东或者淘宝他们是怎么做的呢？一般他们的筛选条件都很复杂他们是怎么做的呢？一点缓存没有吗？还是他们的缓存就没在程序这一层设计？
解决方案四：
我在想这个可能就跟加索引一样把缓存key值关联到最能细致筛选条件的一个条件上比如我这有个省市的选择我就加在这个省市上第一次把这个市的数据全查出来以后再碰到这个市的细致条件就在这个市的结果集上去筛选。。。还得再想想。。那如果他就没选市那个条件呢？
解决方案五：
该回复于2012-03-11 08:53:14被版主删除
解决方案六：
引用楼主pang51a的回复:
有没有好的思路可以说下各位大神我觉得主要是这个缓存的key怎么处理还有分页一个严格的查询条件可能只是一个宽松条件的子集我想是如果以前缓存过这个宽松的条件我就不用再查数据库而是利用这个缓存再进一步的利用linq删选结果但是涉及到分页我那个宽松的条件可能只是缓存了部分数据不是全部的可是如果我把缓存规则定的太死比如完全按照条件和页数去匹配我又感觉命中率肯定不高。。……
命中率不高什么意思呢？你是不是认为假设把10万条记录放到内存里那么命中率就“高”了？如果是，那么你说的所谓命中率完全就不是真正的命中率了！这就是我对你所谓的“缓存了全部的数据”的看法，你的命中率概念完全是相反的。假设我们只是缓存一条数据，而不是10万条数据，这一条的命中率是很高的。因为你想，假设你把10万条记录一起作为一个缓存单元，那么这个缓存单元的命中率是不是就完全等于最低点的一条记录的命中率？而你把10万条记录中的1000条缓存，无论如何其平均命中率要比这个大的缓存单元高许多许多倍！一个分页查询，你可以用其sql语句作为缓存的key。即时是这个页面中数据在其它的查询缓存中有重复，也没有关系。也比你一下在缓存什么几万条数据命中率高多了。更何况.net的cache有很高的智慧，会自动根据内存情况自动清理内存占用，所以根本不用担心不同的数据缓存中有重复的数据。关键是使用相同的key查询时根本不用再次重复查询，这就够了。
解决方案七：
引用3楼pang51a的回复:
我在想这个可能就跟加索引一样把缓存key值关联到最能细致筛选条件的一个条件上比如我这有个省市的选择我就加在这个省市上第一次把这个市的数据全查出来以后再碰到这个市的细致条件就在这个市的结果集上去筛选。。。还得再想想。。那如果他就没选市那个条件呢？
这是空想。数据缓存的原则就两条：1.简单傻瓜化而不要想当然地搞什么“聪明的”分层查询；2.当真实数据修改时必须尽快（立刻）删除缓存。
解决方案八：
你把10万条记录中的1000条缓存，哪怕是很傻瓜化地一条一条地缓存，无论如何其平均命中率也要比这个大的缓存单元高许多许多倍！更何况你是对查询页面做缓存！数据缓存就好象给软件做皮肤、搞交互设计一样，是“立竿见影”地对性能产生极端影响的。不是那种花费好多时间研究一大堆理论结果对测试结果的影响很小的技术。你就是要从最终的查询设计出发去直截了当地缓存就行了，不要太繁琐。
解决方案九：
果以前缓存过这个宽松的条件我就不用再查数据库而是利用这个缓存再进一步的利用linq删选结果但是涉及到分页我那个宽松的条件可能只是缓存了部分数据不是全部的>>>>>>>>>>>>>>>>>>>?>??????????????????????????这里叫我很迷茫,您说是子集为什么数据不全啊您要开缓存当然要开最大的您完全可以规定,分页不查询数据库的,或者10%2不查询命中率,应该是100的,及我们缓存开最大开销