ThinkPHP 官方从6.0起移除partition分表支持，5.x仅保留无效配置；实际分表需手动计算表名并调用table()或重写getTable()，路由与中间件无法自动分表，原生MySQL分区亦不被框架优化支持。
ThinkPHP 的 partition 分表策略实际不生效？
因为 ThinkPHP 官方从 6.0 开始就移除了内置的 partition 分表支持，5.x 版本虽保留了配置项（如 partition、partition_field），但仅在极少数旧版驱动（如原生 PDO + 手动拼 SQL）下有模糊作用，ORM 层根本不会解析或应用它。你看到的“分表查询”基本是靠自己拼表名、手动切换模型或重写 table() 实现的。
常见错误现象：Db::name('user')->partition(12)->select() 没报错但查的还是 user 表；配置里写了 'partition' => ['type' => 'hash', 'num' => 4] 却完全没反应。
- ThinkPHP 5.1+ 的
Query类里没有partition()方法，调用会静默忽略 -
partition配置项只被早期的Model构造逻辑读取过一次，且未与查询构建器联动 - 官方文档中相关章节已归档，新版文档彻底删除该关键词
手动实现按月分表：table() + 时间字段动态计算
这是最常用也最可控的方式——放弃幻想，自己算表名。比如日志表按月分表为 log_202401、log_202402，核心是把时间字段映射到表后缀，再传给 table()。
使用场景：写入和查询都明确知道时间范围（如查“2024年3月订单”），且能接受按时间预估表名。
立即学习“PHP免费学习笔记（深入）”；
- 别在
where里直接写create_time >= '2024-03-01'后指望框架自动跳转表——它不会 - 必须提前算出表名，例如：
$tableName = 'order_' . date('Ym', strtotime('2024-03-15')); - 然后用
Db::table($tableName)->where(...)->select()，或继承Model后重写getTable()方法 - 注意时区：
date()受 PHP 默认时区影响，和数据库存储时间不一致会导致跨月错表
路由规则无法自动识别分表？那就别让它识别
ThinkPHP 路由匹配的是控制器/方法，不是数据表。所谓“路由解析分表”本质是误解——没人会把 /api/user/202403 这种 URL 直接映射到 user_202403 表，而是你在控制器里拿到 202403 参数后，手动构造表名。
常见错误：试图在路由定义里写 ['pattern' => ['table_suffix' => '\d{6}']] 并期望框架自动注入到模型分表逻辑中——这不存在。
- 路由参数只是字符串，需显式转换：例如
$suffix = $this->request->param('suffix');，再校验是否符合\d{6} - 若不做校验，攻击者可能传
../../etc/passwd类路径，拼出非法表名导致 SQL 报错或信息泄露 - 不要把分表逻辑塞进中间件做“全局切换”，不同接口查的表后缀不同，状态容易污染
为什么不用 MySQL 的 PARTITION BY RANGE？
因为 ThinkPHP 对原生分区表支持有限：它生成的 SELECT 语句不会加 PARTITION(p202403) 提示，MySQL 仍会扫描所有分区（除非 WHERE 条件能触发分区裁剪）。而你自己拼表名，等于强制走单表，性能更稳。
性能影响很实在：原生分区表在百万级数据下，WHERE create_time BETWEEN ... 若没命中分区键，查询可能比单表还慢；而 user_202403 是纯粹的 B+ 树查找。
- 原生分区要求主键必须包含分区字段，这常和 ThinkPHP 的自增主键习惯冲突
- 运维复杂：新增分区、合并分区需 DBA 操作，不能靠代码自动完成
- 备份恢复麻烦：mysqldump 默认导出所有分区，没法按需导单个逻辑表
真正难的不是怎么写代码，是设计分表边界时要不要考虑历史数据迁移、跨表聚合统计、以及那个永远没人记得改的“默认表” fallback 逻辑。
