看到一篇頗有趣的討論, 很多論點呢

http://www.phpx.com/happy/archiver/tid-257682.html

php 寫下mysqli 的class 時沒有把caching 包含進去令到人們十分的不方便, 人們把以前mysql 的做法再一次放到mysqli 上

這個類的評價的地方實在很多, 首先用object 的alias 去套進另一個class 中已經是人們十分不願看到的一件事
不過最多評價還是在caching 上

樓主所用的是serialize 和deserialize, 我一直覺得效率已經十分好了

但樓下的點評也有很多資訊值得記下

理论上,mysql在读取数据前是经过一系列的判断操作之后再开始读取数据.

把要查询的东西生成一很简单的txt文档之后,直接读取的速度是要大大的快过从库里查询的.而且CPU或内存的使用量也应该要远远小于从库中查询才对.

====================================

那只是理论,但实际上并非如此
[code]for($i=0;$i<100;$i++) {
        $sql = "select * from words as a left join relative_words as b on a.word_id=b.word_id  limit 0,1000";
        //$res = $db->get_all($sql);
        $res = $db->cache_all($sql);
}[/code]
结果很诡异,前者
cost 1.00315293312 seconds
后者
cost 1.16315293312 seconds

=====================================

我的测试结果是相反的。最简单的取一条数据也是文本缓存的快一些。可能你缓存类的初始化过程比较费时间。

=====================================

反序列化双刃剑,如果数据较多,数组较复杂,就比较烦了

既然是cache就有命中率一说

数据库也是要走IO的,文件也是IO,文件cache配合内存cache效果会很好,通过优化cache,根据需求合理使用才是正确的选择(究竟如何才是合理呢...下面有答案)

=====================================

一般情况下用文本“缓存”绝对是大站的恶梦(google fs这类除外),轻量级应用还凑和,大型应用根本不行,也不可靠。

并行读写、ACID...

=====================================

这几天忙,没来看,多谢各位的回复。

关于单文件夹,这个其实在实际使用的时候是下面还有2级的文件夹,截取的md5前4位

单次查询其实走的还是mysql,第二次及更多查询的时候才是走文本缓存。

后来又做了些测试,当多表联查的时候,文本缓存还是有优势的,但是现在刻意只将数据在4k以下的做缓存,超过4k因为会分到磁盘的两个簇中,存放位置不一定连续,所以不使用

在无法使用memcache或者tt的情况下这个东西还是有点用处,关于并行读写,现在我还没发现什么问题

======================================

樓主最後的回覆真的是要點...究然連4k 一個簇也考慮進去了
那麼站點可以考慮把cluster size 很大(約16kB)的一個磁碟作為caching 使用, 反正對於伺服器來說, 磁碟機空間常常有很多但只是帶寬和cpu 不夠而已