CodeIgniter数据库查询缓存需手动配置路径、按需开启cache_on()、增删改后必须手动清理，仅SELECT查询被缓存且无自动失效机制；路径须为绝对路径并确保Web用户可写，全局开启易致实时数据异常。
CodeIgniter 的数据库查询本身不带自动缓存，必须显式配置路径、开启开关、控制生命周期——漏掉任一环，cache_on() 都不会生效，你看到的“没变快”不是错觉，是根本没缓存上。
缓存目录路径必须绝对且可写
别用 'cache/' 这种相对路径，它会从当前执行脚本（比如 index.php）位置开始找，99% 情况下找不到；必须用 APPPATH.'cache/database/' 或 WRITEPATH.'cache/database/'（CI4）。路径设完立刻验证：
-
ls -l APPPATH.'cache/database/'看目录是否存在 -
touch APPPATH.'cache/database/.test && rm APPPATH.'cache/database/.test - 确认 Web 用户（如 www-data、apache）有写权限，chmod 755 不够，通常要 775
别全局开 cache_on，按需开关才可控
在 application/config/database.php 里设 'cache_on' => TRUE 是最危险的配置：所有 SELECT 查询（包括后台管理页、实时搜索、用户会话检查）全被缓存，改完数据刷不出来，第一反应就是“系统崩了”。更稳妥的做法是：
- 只在明确需要缓存的控制器方法开头调用
$this->db->cache_on() - 查完立刻关掉：
$this->db->cache_off()，避免后续意外缓存 -
cache_on()只影响之后的get()、query()等读操作，INSERT/UPDATE完全不进缓存，不用关
cache_delete_all() 和 cache_delete() 必须手动调
CodeIgniter 缓存没有 TTL，不自动过期。增删改后不清理，缓存就永远 stale。常见误操作是以为“SQL 改了缓存就自动换”，其实只要 SQL 字符串不同（哪怕多一个空格），就生成新缓存文件，旧的还在磁盘里躺着。
- 发布新内容后全量清空：
$this->db->cache_delete_all() - 只清某个控制器方法的缓存：
$this->db->cache_delete('blog', 'index')，对应Blog::index()生成的缓存子目录 - 缓存文件结构是
cache/database/default+controller_method/[md5_hash]，直接rm -rf cache/database/default+blog_index也有效
哪些查询压根不会进缓存？先确认再折腾
不是所有 SELECT 都能缓存，也不是所有写操作都“忽略缓存”就等于安全。以下情况缓存系统直接跳过，不报错也不存，白忙活：
-
INSERT、UPDATE、DELETE、TRUNCATE—— 缓存层完全不处理 - 带绑定参数的查询（如
$this->db->where('id', $id)->get('users')）能缓存，但缓存键含具体值，$id=1和$id=2是两个独立缓存文件 -
->unbuffered_row()这类流式读取不支持缓存（CI 3.x/4.x 均如此） -
SELECT后接->result()、->row()、->num_rows()没问题，但缓存只保存原始结果集，不重算行数或类型转换
最常被忽略的一点：缓存文件生成后，如果后续查询 SQL 字符串完全一致（包括空格、换行、参数值），才会命中；一旦控制器逻辑变了、参数变了、甚至只是加了个注释，就生成新缓存——而旧缓存还占着磁盘，既不提醒也不清理。
