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月订单”），且能接受按时间预估表名。

• 别在 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 逻辑。

php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！