4k 之內
看到一篇頗有趣的討論, 很多論點呢
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 不夠而已