内存数据库有现成的redis，高效存取键值对，键设为你的查询条件，值设为你的查询结果转为字符串
查询时先从redis取，没有再查数据库，并且设置redis的过期时间，这种方式需要项目对实时性要求不高，这样你才能用缓存，而且如果你的项目没有明显的热点，即没有某些内容确定会多次被查到，那你缓存就不会命中，添加缓存反而影响你得速度
redis是一种nosql的内存数据库，感兴趣你可以了解一下，优点就是性能强劲
数据查询请求多就把结果缓存下来，你查数据库再快也没有直接把结果从内存读出来快
同样的sql请求只有第一次查数据库，之后通通读内存
或者你干脆借助这种思想，创建一个全局的map对象，然后查询条件作key
，结果作value，就省去了了解redis的过程，把整个数据库装内存不太科学，你有多少条数据啊
‘贰’ 在PHP中怎么对数据进行缓存读取功能
1、普遍缓存技术：
数据缓存：这里所说的数据缓存是指数据库查询PHP缓存机制，每次访问页面的时候,都会先检测相应的缓存数据是否存在，如果不存在，就连接数据库，得到数据，并把查询结果序列化后保存到文件中，以后同样的查询结果就直接从缓存表或文件中获得。
用的最广的例子看Discuz的搜索功能，把结果ID缓存到一个表中，下次搜索相同关键字时先搜索缓存表。
举个常用的方法，多表关联的时候，把附表中的内容生成数组保存到主表的一个字段中，需要的时候数组分解一下，这样的好处是只读一个表，坏处就是两个数据同步会多不少步骤，数据库永远是瓶颈，用硬盘换速度，是这个的关键点。
2、 页面缓存：
每次访问页面的时候，都会先检测相应的缓存页面文件是否存在，如果不存在，就连接数据库，得到数据，显示页面并同时生成缓存页面文件，这样下次访问的时候页面文件就发挥作用了。(模板引擎和网上常见的一些PHP缓存机制类通常有此功能)
3、 时间触发缓存：
检查文件是否存在并且时间戳小于设置的过期时间,如果文件修改的时间戳比当前时间戳减去过期时间戳大，那么就用缓存，否则更新缓存。
4、 内容触发缓存：
当插入数据或更新数据时，强制更新PHP缓存机制。
5、 静态缓存：
这里所说的静态缓存是指静态化，直接生成HTML或XML等文本文件，有更新的时候重生成一次，适合于不太变化的页面，这就不说了。
以上内容是代码级的解决方案，我直接CP别的框架，也懒得改，内容都差不多，很容易就做到，而且会几种方式一起用，但下面的内容是服务器端的缓存方案，非代码级的，要有多方的合作才能做到
6、 内存缓存:
Memcached是高性能的，分布式的内存对象PHP缓存机制系统，用于在动态应用中减少数据库负载，提升访问速度。
7、 php的缓冲器：
有eaccelerator， apc， phpa，xcache，这个这个就不说了吧，搜索一堆一堆的，自己看啦，知道有这玩意就OK
8、 MYSQL缓存：
这也算非代码级的，经典的数据库就是用的这种方式，看下面的运行时间，0.09xxx之类的
9、 基于反向代理的Web缓存:
如Nginx，SQUID，mod_proxy(apache2以上又分为mod_proxy和mod_cache)
‘叁’ 怎么实现redis的数据库的缓存(redis实现缓存的流程)
大致为两种措施：
一、脚本同步：
1、自己写脚本将数据库数据写入到redis/memcached。
2、这就涉及到实时数据变更的问题（mysqlrowbinlog的实时分析），binlog增量订阅Alibaba的canal，以及缓存层数据丢失/失效后的数据同步恢复问题。
二、纯贺业务层实现：
1、先读取nosql缓存层，没有数据再读取mysql层，并写入数据到nosql。
2、nosql层做好多节点分布式（一致性hash），以及节点失效后替代方案（多层hash寻找相邻替代节点），和数据震荡恢复了。
redis实现数据库缓存的分析：
对于变化频率非常快的数据来说，如果还选择传统的静态缓存方式（Memocached、FileSystem等）展示数据，可能在缓存的存取上会有很大的开销则裤差，并不能很好的满足需要，而Redis这样基于内存的NoSQL数据库，就非常适合担任实时数据的容器。
但是往往又有数据可靠性的需求，采用MySQL作为数据存储，不会因为内存问题而引起数据丢失，同时也可以利用关系数据库的特性实现很多功能。所以就会很自然的想到是否可以采用MySQL作为数据存孙皮储引擎，Redis则作为Cache。
MySQL到Redis数据复制方案，无论MySQL还是Redis，自身都带有数据同步的机制，比较常用的MySQL的Master/Slave模式，就是由Slave端分析Master的binlog来实现的，这样的数据复制其实还是一个异步过程，只不过当服务器都在同一内网时，异步的延迟几乎可以忽略。那么理论上也可用同样方式，分析MySQL的binlog文件并将数据插入Redis。
因此这里选择了一种开发成本更加低廉的方式，借用已经比较成熟的MySQLUDF，将MySQL数据首先放入Gearman中，然后通过一个自己编写的PHPGearmanWorker，将数据同步到Redis。比分析binlog的方式增加了不少流程，但是实现成本更低，更容易操作。
‘肆’ Java中怎么把数据库中的表做成定时任务，存入缓存，减轻频繁直查数据库时，数据库的压力
根据你的想法，建议将两种方式整合下，建议如下设置：
接根据业务层的需要，把频繁使用的多个表数据进行整合，并利用视图的方式进行访问，这样既能减少数据表的压力，也能保持数据的准确性；
根据向系统设定场景，将经常使用到的数据存放在缓存中，缓存建议使用radis等非关系型数据库；
根据数据量确定，数据量比较大的，可以使用中间表等方式，如果数据量小而多的，放在缓存中最好，提高命中率。
‘伍’ 数据库缓存机制是什么缓存是如何作用数据库
我们都知道MySQL的TableCache是表定义的缓存，江湖上流传着各种对这个参数的调优方法。
tablecache的作用，就是节约读取表结构文件的开销。对于tablecache是否命中，其实tablecache是针对于线程的，每个线程有自己的缓存，只缓存本线程的表结构定义。不过我们发现，strace中没有关于表结构文件的open操作（只有stat操作，定位表结构文件是否存在），也就是说tablecache不命中闹亮罩，不一定需要读取表结构文件。这种感觉好像是：在不命中tablecache时，命中了另外一个表结构缓存。
运维建议：
我们读一下MySQL的文档，关于table_open_cache的建议值公式：建议值=最大并发数*join语句涉及的表的最液闹大个数。
通过实验我们键迅容易理解：table_cache是针对于线程的，所以需要最大并发数个缓存。另外，一个语句join涉及的表，需要同时在缓存中存在。所以最小的缓存大小，等于语句join涉及的表的最大个数。将这两个数相乘，就得到了MySQL的建议值公式。
‘陆’ 如何缓存数据库一张表 c#
看你的系统是BS还是CS结构的。如果是CS，前台控件可直接绑定，然后可进行查询等操作。如果是BS，建议不要用服务器控件在页面。采用Webservice吧。前台用html
‘柒’ 如何用redis/memcache做Mysql缓存层
1、首先明确是不是一定要上缓存，当前架构的瓶颈在哪里，若瓶颈真是数据库操作上，再继续往下看。
2、明确memcached和redis的区别，到底要使用哪个。前者终究是个缓存，不可能永久保存数据（LRU机制），支持分布式，后者除了缓存的同时也支持把数据持久化到磁盘等，redis要自己去实现分布式缓存（貌似最新版本的已集成），自己去实现一致性hash。因为不知道应用场景，不好说一定要用memcache还是redis，说不定用mongodb会更好，比如在存储日志方面。
3、缓存量大但又不常变化的数据，比如评论。
4、思路是对的，清晰明了，读DB前，先读缓存，如果有直接返回，如果没有再读DB，然后写入缓存层并返回。
5、考虑是否需要主从，读写分离，考虑是否分布式部署，考虑是否后续水平伸缩。
6、想要一劳永逸，后续维护和扩展方便，那就将现有的代码架构优化，按你说的替换数据库组件需要改动大量代码，说明当前架构存在问题。可以利用现有的一些框架，比如SpringMVC，将应用层和业务层和数据库层解耦。再上缓存之前把这些做好。
7、把读取缓存等操作做成服务组件，对业务层提供服务，业务层对应用层提供服务。
8、保留原始数据库组件，优化成服务组件，方便后续业务层灵活调用缓存或者是数据库。
9、不建议一次性全量上缓存，最开始不动核心业务，可以将边缘业务先换成缓存组件，一步步换至核心业务。
10、刷新内存，以memcached为例，新增，修改和删除操作，一般采用lazy load的策略，即新增时只写入数据库，并不会马上更新Memcached，而是等到再次读取时才会加载到Memcached中，修改和删除操作也是更新 数据库，然后将Memcached中的数据标记为失效，等待下次读取时再加载。
大方向两种方案：
1、脚本同步：
自己写脚本将数据库数据写入到redis/memcached。
这就涉及到实时数据变更的问题（mysql row binlog的实时分析），binlog增量订阅Alibaba 的canal ，以及缓存层数据 丢失/失效 后的数据同步恢复问题。
2、业务层实现：
先读取nosql缓存层，没有数据再读取mysql层，并写入数据到nosql。
nosql层做好多节点分布式（一致性hash），以及节点失效后替代方案（多层hash寻找相邻替代节点），和数据震荡恢复了。
‘捌’ 11.33数据缓存的好处是什么，如何实现数据缓存
数据库缓存的作用是只在数据第一次被访问时才从数据库中读取数据，将数据放在存储介质中，以后查询相同的数据则直接从存储介质（内存）中返回，这样速度有明显的提升。
为了更好的使用数据缓存，应注意以下几点：
1、如果一个实体标记了缓存属性，则无论该类是 通过ID查询还是其它方式的查询得到的结果，都会自动缓存。 所以，不必担心结果是否能够按照预期的需要缓存。
2、查询缓存如何使用？ 在CastleActiveRecord中的查询类没有提供对查询缓存的支持，只能使用NHibernate的查询才可以，例子如上所述。
3、缓存的性能，缓存在一定程度上可以提高应用的性能，但需要正确使用，如果使用不慎，缓存反而成为负担，比如，在应用中如果使用NHibernate.Caches.Prevalence 作为缓存提供程序，如果数据量大，它要在指定目录下写入缓存文件，IO消耗相当大，虽然数据库访问少了，但是应用的IO却增长，还不如不使用缓存。因此，使用缓存时应尽量避免使用文件型缓存，应使用内存型缓存。
4、缓存的策略。查询缓存应只对只读性数据进行缓存，如果是经常读写的数据，可能造成数据不一致，至于造成数据不一致的原因没有花时间根究。
5、如果实体有继承关系，必须在被继承的类上也标记使用 缓存，否则，子类的缓存无效。
6、如果对查询进行缓存，必须实体也要标记缓存，否则查询缓存无效。