分表逻辑必须由模型层主动控制，需重写gettablename()或动态设table，禁用硬拼表名、严格校验后缀、统一用datetime索引、php合并聚合查询。
分表逻辑必须由模型层主动控制，不能依赖数据库中间件
ThinkPHP 本身不提供自动分片路由，Db 或 Model 不会根据主键或时间自动切到 user_202401 这类表。你得在查询前就决定用哪张物理表——否则查的永远是配置里写的默认表名。
常见错误现象：Undefined table: 1146 Table 'db.user' doesn't exist，其实是代码还在查基础表名，但实际数据已按月拆到 user_202401、user_202402 里。
- 所有涉及分表的模型，需重写
getTableName()方法，或在initialize()中动态设置$this->table - 避免在
where条件里用table('user_'.date('Ym'))硬拼——这会导致 ORM 失去关联、预处理失效 - 如果用
scope封装分表逻辑，注意 scope 不影响getTableName()，仍需提前切换表名
按时间分表时，create_time 字段必须索引且类型为 DATETIME 或 TIMESTAMP
按月分表最常用，但容易忽略字段类型和索引问题：若 create_time 是 VARCHAR 存 "2024-01-01"，MySQL 无法高效 range 分区，WHERE create_time >= '2024-01-01' 可能全表扫描。
使用场景：用户注册日志、订单记录等有强时间维度的数据。
- 建表时统一用
DATETIME，别用字符串模拟时间 - 每个分表都必须单独为
create_time建索引，ThinkPHP 不会帮你跨表建 - 分表命名建议用
log_202401而非log_2024_01，避免下划线干扰解析逻辑
Db::name() 动态调用要防 SQL 注入，别直接拼接用户输入
有人写 Db::name('order_'.$_GET['month'])->select()，这是高危操作。攻击者传 month=202401; DROP TABLE order_202401 虽然不会执行（PDO 预处理限制），但可能触发异常或绕过校验。
参数差异：Db::name() 接收字符串，不做任何过滤；而 where() 中的值会被参数化，但表名永远不会。
- 严格校验分表后缀：只允许
^\d{6}$（如 202401），拒绝任何字母、符号、超长数字 - 把合法分表名缓存在数组或 Redis 中，运行时只做白名单匹配
- 不要用
__TABLE__占位符 +str_replace，那等于自己造注入点
跨分表聚合查询只能靠 PHP 合并，别指望 UNION ALL 自动优化
想查“最近三个月总订单数”，不能写 SELECT COUNT(*) FROM (SELECT * FROM order_202401 UNION ALL SELECT * FROM order_202402 ...) —— ThinkPHP 的 union() 不支持跨库/跨物理表的复杂嵌套，而且 MySQL 对 UNION 的索引利用极差。
性能影响：单表查 10ms，三张表并发查再 PHP 合计，通常比一条 UNION 快 2–5 倍，还容易加缓存。
- 用
Swoole\Coroutine\Channel或pcntl_fork并发查多张表（仅限 CLI 场景） - Web 请求中老实用 for 循环 +
Db::name($table)->count()，配合cache()缓存结果 - 避免在分表场景下用
withCount()关联统计，它会为每条主记录发起一次分表查询
分片不是加个配置就能跑起来的事，表名怎么生成、时间字段怎么查、用户输入怎么拦、聚合怎么算——每个环节漏一环，线上就查慢或丢数据。尤其是 getTableName() 的调用时机和 Db::name() 的校验，最容易在压测时才暴露。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
