CodeIgniter 3需手动实现按年月自动分表，核心是动态设置模型的$table属性；推荐通过SplitTableTrait的init()或setSuffix()控制表名，并将建表逻辑移至命令行脚本预创建，查询时应封装getByTimeRange等方法统一处理跨表聚合与分页。
CodeIgniter 3 本身不内置分表机制，必须靠手动切换 $this->table 属性 + 动态建表逻辑来实现；直接改模型的 table 属性是可行路径，但必须确保每次查询前都重置、且避免并发写入时表名错乱。
如何让模型支持按年月自动切换分表（如 b_log_202604）
核心是控制模型实例的 $table 属性在查询前被正确覆盖。参考 SplitTableTrait 的做法：在模型构造或业务入口处调用 init() 或 setSuffix()，它会把 $this->table 改成带后缀的最终表名。
-
init()适合初始化时统一设置（比如控制器加载模型后立刻调），会自动取当前Ym并触发createTable() -
setSuffix('202603')更灵活，适合按业务参数（如用户上传时间）查历史分表，但必须在$this->db->get()前调用 - 务必注意：
setSuffix()内部会执行$this->table = $this->originTable . '_' . $this->suffix，所以原表名不能含下划线，否则生成log_202604_202603这类错误表名 - 如果模型继承自
CI_Model而非自定义基类，需确保$this->originTable在__construct()中已赋值为原始表名，否则$this->originTable . '_' . $suffix会拼出空字符串
为什么 createTable() 容易引发重复建表或权限失败
该方法通常用 $this->db->query("CREATE TABLE IF NOT EXISTS ...") 实现，但 CI 3 的 query() 不返回具体错误码，只抛异常或静默失败。线上环境若数据库用户无 CREATE 权限，就会卡住或报错却难以定位。
- 建表语句必须严格匹配原表结构（含引擎、字符集、索引），不能只靠
SHOW CREATE TABLE复制——CI 3 的db->list_fields()不返回字段注释和默认值，容易漏掉DEFAULT CURRENT_TIMESTAMP这类关键定义 -
IF NOT EXISTS只防同名表，不防结构差异。若某次手动改过原表结构但忘了同步到分表逻辑，后续写入可能因字段缺失报错 - 建议把建表逻辑抽离为独立命令行脚本（如
php index.php tools create_table b_log 202604），由运维定期预建下月分表，而非运行时动态创建
分表后列表查询怎么避免跨表漏数据或重复计数
分表本质是水平拆分，单次查询只能命中一张物理表。若要查「最近 3 个月所有日志」，就必须分别查 b_log_202602、b_log_202603、b_log_202604 三张表再合并结果——CI 3 的查询构造器不支持 UNION 链式调用，得手写 SQL 或循环拼数组。
- 分页会变得极其复杂：总条数不是
count_all_results()一次能拿的，得对每张目标分表分别count再累加；偏移量（offset）也需换算成各表内的局部偏移，否则跳过第一条数据就错位 - 如果业务允许，优先用「按时间路由」代替「全量扫描多表」：比如用户查「2026-04-15 的日志」，直接算出后缀
202604，只查一张表，性能可控 - 别依赖
$this->db->like()等模糊条件跨表查——不同分表间数据无序，ORDER BY created_at LIMIT 10在每张表里取 10 条，合并后可能丢失真实 Top10
真正麻烦的不是建表或切表，而是查询边界：时间范围怎么映射到后缀、跨表聚合怎么保序、分页 offset 怎么分摊——这些逻辑一旦散落在控制器里，很快就会失控。最稳的方式是把分表策略封装进模型方法，例如 getByTimeRange($start, $end) 内部自动算后缀、分表查询、合并排序，外部只管传时间。
