CodeIgniter数据库性能瓶颈多源于调用方式与架构设计而非SQL本身；应避免视图层直连数据库、消除N+1查询，改用批量查询与模型封装方法提升效率。
CodeIgniter项目中数据库操作的性能问题，往往不是出在SQL本身，而是出在调用方式、数据组织逻辑和架构层级上。真正影响响应速度的，常是重复查询、未加索引的WHERE条件、视图层直连数据库，以及模型职责不清导致的冗余处理。
避免视图层直接查库
这是最常见也最容易被忽视的性能隐患。比如在循环渲染菜单时，每个菜单项都单独查一次子菜单：
- ❌ 错误做法：视图里写
$this->db->query("SELECT * FROM submenu WHERE id_mainmenu = $id") - ✅ 正确做法：控制器中一次性查出全部主菜单+子菜单，用PHP做关联映射后传给视图
- 关键点：把N+1查询压成1次联合查询或2次分步查询（如先取所有mainmenu，再用
IN()批量取对应submenu）
善用模型方法替代Query Builder硬编码
直接用$builder->update()容易漏掉where()，还难复用和测试。模型封装后，逻辑集中、可加验证、可触发事件：
- 更新单条记录：用
$model->update($id, $data)，ID必须明确，杜绝全表更新风险 - 批量更新：用
$model->updateBatch($data, 'id')，比循环调用update()快得多 - 带条件更新：用
$model->set(['status' => 'done'])->where('created_at update()
合理使用缓存与连接复用
CI默认开启持久连接，但还需主动干预高频读场景：
- 静态配置页、分类列表等不常变的数据，用
$cache = \Config\Services::cache(); $cache->save('menu_tree', $data, 3600); - 查询前先
if ($cached = $cache->get('user_profile_'.$uid)) { return $cached; } - 避免在模型方法里反复
$this->db = \Config\Database::connect();，模型已自带DB实例
索引与查询精简不可跳过
框架再优化，也救不了没索引的WHERE字段或SELECT *
- 对常用于
WHERE、ORDER BY、JOIN的字段建索引（如user_id、status、created_at） - 用
select('id, title, slug')代替select('*')，尤其当表有TEXT或JSON字段时 - 分页查大数据集，优先用
limit()+offset()，而非paginate()自动计算总数（可改用估算或缓存总数）
