TP5.1 的 partition() 方法在绝大多数场景下不生效,ORM 查询构建器不会解析该配置;动态分表必须手动计算表名并通过重写 getTable() 或 Db::table() 实现,且需确保写入与查询逻辑严格一致。
TP5.1 的 partition() 方法看似可用,实则在绝大多数场景下不生效——它只在极少数旧驱动路径中被浅层读取,ORM 查询构建器(Query 类)根本不会解析或应用该配置。所谓“动态分表”,必须靠手动计算表名 + 显式切换实现。
模型的表名最终由 getTable() 方法返回,这是你唯一能稳定拦截并修改表名的位置。不要依赖构造函数传参、protected $table 赋值或配置项,它们在查询执行前就已固化。
getTable() 在每次查询前都会被调用,包括 select()、insert()、update() 等所有操作id 字段(注意:新增时 id 可能尚未生成,需结合 insertGetId() 或预生成逻辑)$this->data 或查询条件(如 $this->getOptions('where'))中提取时间字段值,再格式化为后缀,例如:'log_' . date('Ym', strtotime($timeValue))
log_../etc/passwd 类非法表名;建议白名单过滤或正则断言:preg_match('/^d{6}$/', $suffix)
当模型逻辑复杂、或仅某几个接口需要分表时,放弃继承模型,直接用查询构建器更清晰可控。
$tableName = 'order_' . date('Ym', strtotime($dateParam));
Db::table($tableName)->where('user_id', 123)->select();
(new OrderModel())->table($tableName)->where(...)->select(),但需确保 OrderModel 中未硬编码 $table
partition() 在 TP5.1 的 Query 类中确实存在,但它只在特定条件下触发:必须同时满足「当前有 where 条件包含分表字段」+「规则匹配成功」+「未开启联合查询 fallback」。多数情况下它静默失败,回退到主表。
Model::partition(['id' => 100])->where('status', 1)->select() —— 此处 id 不在 where 中,partition() 直接忽略where('id', 100)->partition(...),若规则中 type 为 mod 且 num 为 3,则只生成 table_1、table_2、table_3,而实际表可能是 table_001、table_002,后缀不匹配照样查不到真正难的不是算表名,而是保持写入与查询逻辑严格一致——比如按月分表,写入用 date('Ym', $create_time),查询却用了 date('Ym', time()),跨月时必然漏数据。所有时间计算必须基于同一字段、同一时区、同一格式化逻辑,且不能依赖 PHP 默认时区或数据库时区自动转换。