分表必须绕开 Laravel 的 Eloquent 默认机制
Laravel 的 Model 天然假设单表结构，select * from users 这种查询不会自动变成 select * from users_2024。硬套 setTable() 或动态改 $table 属性，会在关联、软删除、批量操作时崩——比如 with('posts') 仍会查原始表名，而你手动切的分表可能根本没关联字段。
实操建议：
- 分表逻辑必须下沉到 Query Builder 层，避开 Eloquent 的生命周期（如
boot()、creating事件） - 用
DB::table($dynamic_table_name)替代Model::query()，哪怕多写几行 - 如果非要保留模型，把
$table设为占位符（如'users_partition'），再通过toSql()+ 字符串替换兜底——但仅限只读场景，写入时务必重写insert()和update()
按时间分表时，where 条件必须带分区键
MySQL 的分区裁剪（partition pruning）只在 WHERE 显式包含分区字段时生效。比如按 created_at 年份分表，但查询写成 where id = 123，MySQL 会扫所有子表——性能比不分表还差。
常见错误现象：
- 分表后查询变慢，
EXPLAIN PARTITIONS显示partitions: NULL - 日志里大量
SELECT ... FROM users_2022, users_2023, users_2024
使用场景：订单、日志、消息记录等天然有时序特征的数据。
实操建议：
- 所有查询必须带
where created_at between ? and ?或where year(created_at) = ? - 用
DB::raw("YEAR(created_at)")配合groupBy聚合时，确保该字段也在where中出现过 - 避免在分区键上用函数做条件，比如
where date_format(created_at, '%Y') = '2024'会失效
DB::transaction() 跨分表写入会失败
MySQL 的事务不跨物理表（即使逻辑同名）。当你在一个事务里对 orders_2023 和 orders_2024 同时 insert，InnoDB 无法保证原子性——其中一个成功、另一个失败时，事务回滚不了。
性能影响：强行用 DB::transaction() 包裹跨表操作，实际退化为应用层补偿逻辑，且死锁概率飙升。
实操建议：
- 单次事务只操作一个分表，靠业务层控制顺序（例如先写
orders_2024，再发消息通知下游处理关联数据） - 需要强一致的场景，改用 TCC 模式或最终一致性，别指望数据库
- 分表路由必须在事务开始前确定，不能在
DB::transaction()里动态计算目标表名
迁移和索引必须手动同步到每个分表
Laravel 的 php artisan migrate 只跑一次，不会自动遍历 users_2022、users_2023… 所有子表。漏建索引的分表，查询直接走全表扫描。
容易踩的坑：
- 开发环境只在
users上加了idx_user_email，上线后发现users_2024没这个索引 - 用
Schema::dropIfExists('users')清库，结果只删了主表，一堆users_*子表残留
实操建议：
- 写迁移文件时，用循环显式操作每个分表：
foreach ($years as $year) { Schema::table("users_{$year}", function (Blueprint $table) { ... }); } - 索引命名带上年份，比如
idx_users_2024_email，避免冲突 - 上线前跑校验脚本：
SHOW INDEX FROM users_2024对比主表结构
分表不是加个中间件就能搞定的事，最麻烦的永远是数据一致性校验和跨分表关联查询的取舍——别省那点代码量，该拆逻辑就拆逻辑。
