前文提及：开放框架应用所遭遇的最大挑战，在于由插件产生的查询方式和数目完全不可控

在享受开源的开放式CMS系统众多插件的使得时，要同时保持页面响应速度，减少插件查询次数的绝对必要。

而开源系统本身已经有的缓存机制，但一般仅针对框架核心做特别优化，插件提供者，很多时候，寄希望于简单的模块缓存机制（Joomla），另一些模块作者，认为上百次查询是无关紧要（joomla有个很关键的商城应用virtuemart就是如此，其他几个流行的最新文章一类的模块也存在这个问题）。

好吧，单独审核每一个模块修订其代码，违背了我们的本意，因此，我们应该考虑的是在核心框架内减少这些查询。

一个可供借鉴的思路是，mysql会尽可能的将查询缓存（query_cache_size），以快速响应请求，但这还不够，成本高过利用memcache一类的缓存机制。
因此，我们的思路是，在框架的database类中，拦截查询请求，不要送往mysql而是在缓存中查找有无直接命中可能——缓存的后端可以是memcache\apc\eacc\file无论经什么。

而对update/insert/replace/delete/alter一类的查询，放行的同时，还需要监控它影响到的是哪些表（OK，我们先考虑影响到的表而不是单独的行和列吧，那是专有系统需要考虑的事情）。一旦这个表发生变更，则我们需要destroy所有和这个表相关的查询请求（有些专有系统会立刻重新生成，但我们等需要时再生成罢）。

那么，接下来很简单了：
1. 构建自有的缓存类，用于和缓存后端交互，读、写、删除，这是至少三个函数，另外，检查是否可缓存，这是一个函数，检查缓存是否过期（随机发生，事实上，若仅通过单一数据库类存取数据库，这一步基本可活力），检查每闪写查询影响哪些表（上文描述，每个缓存的查询和表相关）；
2. 找出数据库类中处理查询的相关函数，在查询前添加检查语句和读函数，查询和添加检查、写和删除函数；
3. 测试并找出被错误缓存或被遗漏的查询，修正检查函数（那么，这一处不同的系统有所不同了，预置一些，高级用户可自行增添）。

代码片断：

此处代码不日添加（joomla已完工但drupal尚在研究中）。

代码量简短，我已经在feminist.cn等几个站点试用，效果颇佳（MYSQL的CPU占用率显著下降），源代码将于近期整理上传。