Laravel中两种用户关联任务删除方式的性能对比

性能对比 #

两种方案的核心差异在于是否多一次数据库查询：

• 方式一：直接执行两条DELETE语句，无额外查询操作，性能更优。对应的底层SQL为：

  DELETE FROM tasks WHERE user_id = ?;
  DELETE FROM users WHERE id = ?;
  

• 方式二：先执行SELECT * FROM users WHERE id = ?查询用户实例，再执行删除任务和用户的语句，比方式一多了一次读查询，性能略逊一筹，但这种差异在常规业务场景下几乎可以忽略。

方案优劣分析 #

方式一（直接硬删） #

• 优势：代码简洁直接，性能最高，无需依赖模型关联定义。
• 劣势：耦合度高，硬编码了外键关联条件（user_id），如果后续tasks表的外键字段名变更，必须手动修改控制器代码，不符合ORM的解耦设计思想。

方式二（利用模型关联） #

• 优势：遵循Laravel Eloquent的关联设计，代码可读性、可维护性更强。后续如果关联关系的定义调整（比如外键字段名修改），控制器代码无需改动，降低了维护成本。
• 劣势：多一次用户查询，性能略低，但在绝大多数业务场景下这种性能差异不会造成影响。

更推荐的最优方案 #

其实还有一种更高效、更可靠的实现：数据库级别的外键级联删除。

在创建tasks表的外键约束时，添加ON DELETE CASCADE属性：

// 迁移文件示例
$table->foreignId('user_id')
      ->constrained()
      ->onDelete('cascade');

之后只需要执行删除用户的操作，数据库会自动删除该用户的所有关联任务：

User::where('id', $user_id)->delete();
// 或
User::find($id)->delete();

这种方案的优势：

1. 性能最优：仅需一条DELETE语句，数据库层面自动处理关联删除，比前两种方式都高效。
2. 代码最简洁：控制器无需额外处理任务删除逻辑。
3. 数据一致性更可靠：避免了应用层逻辑遗漏（比如忘记写删除任务的代码）导致的数据冗余问题。

内容的提问来源于stack exchange，提问作者mhmd k987 karkoutli