CodeIgniter数据库缓存需手动配置路径与权限，按需开启cache_on()，增删改后须手动清理缓存，仅SELECT查询被缓存且不自动失效。
缓存目录权限和路径配置必须手动搞定
CodeIgniter不会自动创建缓存目录，也不会帮你设好写权限——这是90%缓存不生效的根源。你得自己在服务器上建目录、赋权限、再配路径。
-
APPPATH.'cache/database/'是推荐路径，但./cache或WRITEPATH.'cache/'（CI4）也行，关键是该路径真实存在且Web用户可写（如chmod 755或775） - 在
application/config/database.php里配：$db['default']['cachedir'] = APPPATH.'cache/database/'; - 别用相对路径如
'cache/'——它会从当前执行脚本位置找，极大概率错位 - 配完立刻
ls -l确认目录权限，别信“应该可以”
cache_on() 和全局 cache_on 别混用
全局开启（在database.php里设'cache_on' => TRUE）会让所有SELECT查询默认走缓存，看似省事，实则埋雷。
- 全局开启后，连后台管理页的实时数据列表也会被缓存，用户改完数据刷不出来，第一反应是“系统坏了”
- 更安全的做法是按需开启：只在明确需要缓存的控制器方法里调用
$this->db->cache_on();，查完立刻$this->db->cache_off(); -
cache_on()只影响后续的get()、query()等读操作；INSERT/UPDATE本身就不进缓存，无需关 - 注意：
cache_on()开启后，同一请求内后续所有SELECT都会缓存，除非你主动cache_off()
缓存没更新？大概率是忘了清缓存
CodeIgniter的数据库缓存不会自动失效，也没有TTL机制——它只靠你手动删。增删改操作后不清理，缓存就永远 stale。
- 最常用的是
$this->db->cache_delete_all()，适合在管理员发布新内容后全量刷新 - 精细控制用
$this->db->cache_delete('blog', 'index')，对应Blog::index()方法生成的缓存文件夹 - 别指望“改SQL就自动换缓存”——哪怕只多一个空格，缓存键就不同，旧缓存还在，新缓存另存一份，磁盘悄悄涨
- 缓存文件结构是
cache/database/default+controller_method/[md5_hash]，直接删整个default+xxx文件夹也有效
哪些查询根本不会进缓存？别白忙活
只有标准SELECT会被缓存，其他一律跳过——这不是bug，是设计如此。强行塞非SELECT进去，既不报错也不存，纯属浪费调试时间。
-
INSERT、UPDATE、DELETE、TRUNCATE等写操作：缓存系统直接忽略，连日志都不记 -
SELECT带绑定参数（$this->db->where('id', $id)->get()）能缓存，但缓存键包含参数值，所以$id=1和$id=2是两个缓存文件 -
SELECT后接->result()、->row()、->num_rows()都没问题；但->unbuffered_row()这类流式读取不支持缓存 - 使用
query()执行原生SQL时，只有以SELECT开头的才缓存，SELECT * FROM ...行，(SELECT ...)子查询也行，但SET @var=1;不行
缓存文件存的是序列化后的CI_DB_result对象，不是原始SQL结果文本——这意味着你不能手改缓存文件来“作弊”，也意味着一旦模型层逻辑变了（比如加了select()字段），旧缓存返回的数据结构可能跟新代码不兼容。
