CodeIgniter本身不提供数据挖掘功能，其“数据挖掘”实为SQL聚合统计、PHP数据清洗与前端图表展示；应优先用GROUP BY单查询替代N+1循环，正确使用result_array()二维结构，并以HTML表格代替Excel库导出报表。
CodeIgniter 本身不提供数据挖掘能力，它只是一个 Web 框架，没有内置的聚类、分类、关联规则或预测模型功能。所谓“数据挖掘”，在 CodeIgniter 项目中实际指的是：用 SQL 做聚合统计、用 PHP 做清洗与特征构造、再把结果喂给前端图表库或导出为分析报表——这是绝大多数中小项目的真实落地方式。
用 group_by() + select() 替代 N+1 查询做基础统计
很多开发者误以为“数据分析”就得写一堆循环查数据库，结果在控制器里嵌套查询，比如先查所有血型，再对每种血型查一次数量。这不仅慢，还容易因 count_all_results() 调用时机错误导致数据错乱。
- 错误写法：
$this->db->count_all_results()在$this->db->query()之后调用，会重置查询上下文，返回整表行数而非当前条件结果 - 正确做法：把聚合逻辑全交给 MySQL，用单条带
GROUP BY的查询完成 - CodeIgniter 3 的推荐写法：
$this->db->from('packets');
$this->db->select('COUNT(PacketID) AS count, BloodType AS blood_type');
$this->db->where('isAvailable', '1');
$this->db->group_by('blood_type');
$query = $this->db->get();
$data = $query->result_array(); // 得到 [{'count'=>12, 'blood_type'=>'A+'}, ...]
这样既避免多次连接开销，又确保数据原子性；若需排序，接 order_by('count', 'DESC') 即可。
从 result_array() 提取字段值时别跳索引层级
常见错误是把查询结果当“扁平数组”用，直接写 $row['id']，但 result_array() 总是返回二维数组——哪怕只有一行，也是 [0] => ['id' => 123] 结构。
- 错误访问：
$data['id']→ 报Undefined index: id - 安全访问方式：先判空，再取第一行，再取字段：
!empty($data) ? $data[0]['blood_type'] : null - 批量提取时别硬编码索引，用
array_column($data, 'count')或array_column($data, 'blood_type')更稳
导出 Excel 报表时别真用 Excel 库——HTML 表格够用了
CodeIgniter 没有原生 Excel 支持，强行集成 PhpSpreadsheet 会增加部署复杂度和内存压力。而 Excel（.xls）能直接解析合法 HTML 表格，这是被长期验证过的兼容方案。
- 关键三步：设置
Content-Type: application/vnd.ms-excel、Content-Disposition头、输出<table>片段 - 注意字符编码：PHP 输出前确保数据库和页面都用 UTF-8，否则中文会乱码
- 不要在表格里混用
<div>或 JS，Excel 解析器只认标准表格标签
示例片段：
header('Content-Type: application/vnd.ms-excel');
header('Content-Disposition: attachment; filename="report.xls"');
echo '<table><tr><th>血型</th><th>数量</th></tr>';
foreach ($data as $row) {
echo "<tr><td>{$row['blood_type']}</td><td>{$row['count']}</td></tr>";
}
echo '</table>';
exit;
真正的数据挖掘门槛不在框架层，而在你是否把聚合逻辑推给了数据库、是否意识到 result_array() 的固定结构、以及是否愿意用简单协议（如 HTML 表格）替代重型依赖。这些点卡住了，再换框架也解决不了问题。
