如何最大化利用缓存

在查询缓存里面，我这么处理一条查询sql：

 

select o from table where x

 

重点是 o 和 x

 

o是查询结果，x是查询条件

 

查询结果不重要，查询条件需要判断你能否处理得了查询条件。

 

目前，查询条件中带函数的sqlfreyja处理不了。原因很简单，如：select * from user where date_format(createTime,'%y%m') > '....'

这条sql处理不了的原因是 date_format是sql特有函数。不能被表达式语言处理，在维护查询缓存的时候根本就处理不了。

 

select count(*),xx from user where ....这类其实也不好处理。使用缓存就是为了减少数据库的连接次数，并且提高效率。类似于 count(*)这种函数，如果不能在内存中计算 就需要直接查询数据库结果。

 

使用查询缓存和使用场景是息息相关的，他能决定查询缓存是否真的提高了效率。一般的公共数据比较适合使用查询缓存，这类数据的特点是：量少、查询多、更改少。当然，量的多少和查询缓存没太大关系，满足后面2个条件就行了。

 

------前面几篇我提到的被我否定的no update方式缓存，我最近又有了一点新的想法。

 

我发现，一张表的字段可以分为2类：孤立的和群聚的。注意，他们和update频率无关

 

孤立的就是那类很少被用在查询语句里面

群聚的正好相反。

 

如，有时候你有没有想过，为什么用户就这么的操作一次就一定要去update数据库呢？ 如果有，那么说明这个字段属于孤立的字段。因为，这个字段的改变实际上不需要频繁update，只需要在任意一个时间“处理”掉就行了。

好可怜啊，这类字段。你不怎么去关心他们什么时候会序列化到数据库，只用确保最终序列化到数据库就行了。与之相反，如果这个字段涉及到RMB你就不会这么怠慢了。

 

 

新的no update方案就要从这些字段下手。另外，带来的提升的要求比较苛刻。即便是孤立的，如果字段update次数过少，很显然看不出什么提升。能看出显著提升的必定是孤立的、update频繁的字段。

 

只有满足这2个条件，你才会觉得值了。

 

这个功能推出还需要等待另外一个功能：动态update。 虽然hibernate里面不建议开启动态update，但是我想不明白一个问题：为什么我仅仅修改user的level 1改为2 却需要update整条记录？