CodeIgniter数据归档与历史管理方法

本文深入解析了在CodeIgniter框架中实现高效、可靠数据归档与历史管理的核心实践：通过自定义SplitTableTrait动态生成带时间后缀的归档表名（如b_log_202604），规避硬编码与命名陷阱；强调建表操作必须脱离Web请求生命周期，以规避并发冲突和权限风险，并确保归档表结构与原表严格一致；针对跨月查询难题，提出采用原生UNION ALL拼接多表查询、手动对齐字段、分表统计总数并精准分页的落地方案；最终落脚于“业务无感”——所有查询封装方法（如getByTimeRange）需内聚表路由与结果合并逻辑，让历史数据迁移不牵动上层代码，真正实现可维护、可扩展、低侵入的历史数据治理。

CodeIgniter 本身不提供数据归档功能，必须靠手动分表 + 定时迁移 + 查询路由来实现；核心不是“删旧数据”，而是把历史记录挪到带时间后缀的表里，同时保持业务查询无感。

如何用 SplitTableTrait 实现按月归档表名切换

归档的前提是能动态生成目标表名（如 b_log_202604），不能硬编码。SplitTableTrait 的 setSuffix() 是最稳妥的方式：

• setSuffix('202604') 必须在 $this->db->get() 或 $this->db->insert() 前调用，否则仍操作原表
• 确保模型中已定义 $this->originTable = 'b_log'，且原始表名不含下划线，否则 $this->originTable . '_' . $suffix 会拼出 b_log_202604_202603 这类错误名
• 不要在构造函数里直接写死 $this->table = 'b_log_202604'，否则无法复用模型查不同月份

为什么 createTable() 要移出 Web 请求生命周期

归档过程常需自动建新表（如 b_log_202605），但 createTable() 若放在控制器里执行，会面临两个风险：

• 并发请求可能同时触发建表，而 CREATE TABLE IF NOT EXISTS 在 CI 3 中不返回具体错误码，失败时只抛 ErrorException 或静默跳过，线上难排查
• 数据库用户若没 CREATE 权限，Web 请求会卡住或 500，影响主流程
• 表结构必须严格一致：引擎、字符集、索引、DEFAULT CURRENT_TIMESTAMP 等都不能漏——$this->db->list_fields() 不返回默认值和注释，建议用 SHOW CREATE TABLE b_log 导出语句后手动替换表名再执行

怎么让 getByTimeRange() 正确聚合跨表数据

用户查“2026-03 到 2026-05”的日志，实际要扫 b_log_202603、b_log_202604、b_log_202605 三张表。不能简单 UNION ALL 拼 SQL，因为 CI 3 的 Query Builder 不支持多表 UNION 链式调用：

• 改用原生查询：$this->db->query("SELECT * FROM b_log_202603 WHERE created_at BETWEEN ? AND ? UNION ALL SELECT * FROM b_log_202604 ...", [...])
• 分页要小心：LIMIT OFFSET 在 UNION 后才生效，总数得先 SELECT COUNT(*) 分别查各表再累加
• WHERE 条件中的字段名必须全部显式写出，不能依赖 *，否则字段顺序错位会导致数据错乱

归档最难的不是切表，而是让老代码无感知——所有 getByTimeRange()、getLatest() 这类封装方法，必须内部做表名推导和结果合并，否则控制器层一改就是全量回归测试。

今天关于《CodeIgniter数据归档与历史管理方法》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！