DB::statement(“DELETE FROM users WHERE created_at ＜ ‘2020-01-01‘“)；的庖丁解牛

DB::statement("DELETE FROM users WHERE created_at < '2020-01-01'");
这行 Laravel 代码看似简单，实则涉及 数据库抽象层、SQL 执行路径、安全边界、事务上下文、性能影响 等多个工程维度。

一、语法本质：DB::statement() 是什么？

在 Laravel 中，DB::statement() 是 Illuminate\Support\Facades\DB 门面 提供的方法，用于执行不返回结果集的原生 SQL 语句（如 DELETE、UPDATE、INSERT、DDL）。

• 签名：

  public static function statement(string $query, array $bindings = [])
  

• 返回值：void（Laravel 9+）或 bool（旧版），不返回影响行数。
• 适用场景：执行 DML/DDL，且不需要结果集。

✅ 与 DB::select()（返回数组）、DB::unprepared()（用于多语句）形成互补。

二、执行流程：从代码到数据库

1. 门面代理

DB::statement(...) 实际调用：

app('db')->connection()->statement($query, $bindings);

2. Connection 层处理

在 Illuminate\Database\Connection 中：

public function statement($query, $bindings = [])
{
    return $this->run($query, $bindings, function ($query, $bindings) {
        if (empty($bindings)) {
            // 无绑定 → 使用 PDO::exec()
            return $this->getPdo()->exec($query);
        } else {
            // 有绑定 → 使用 prepare + execute
            $statement = $this->getPdo()->prepare($query);
            $this->bindValues($statement, $bindings);
            return $statement->execute();
        }
    });
}

3. 本例的执行路径

• SQL："DELETE FROM users WHERE created_at < '2020-01-01'"
• $bindings：空数组（[]）
• → 走 PDO::exec($sql) 路径

🚨 关键点：因为没有使用参数绑定，Laravel 直接调用 PDO::exec()，而非 prepare() + execute()。

三、安全风险：为什么这是“危险操作”？

1. 硬编码日期 = 可维护性差

• 若需动态日期（如“30天前”），开发者可能拼接字符串：

  // ❌ 危险反模式
  $date = request('before_date');
  DB::statement("DELETE FROM users WHERE created_at < '$date'");
  

• 后果：SQL 注入漏洞（攻击者传 2020-01-01'; DROP TABLE users--）

2. 绕过 Laravel 的安全默认

• Laravel 的 Query Builder（如 DB::table('users')->where(...)) 自动使用参数绑定。
• DB::statement() 放弃此保护，将安全责任完全交给开发者。

🔒 安全原则：永远不要在 SQL 中拼接外部输入。

四、正确替代方案：安全 + 可读 + 可测

✅ 方案 1：使用 Query Builder（推荐）

DB::table('users')
  ->where('created_at', '<', '2020-01-01')
  ->delete();

• 优势：
  • 自动参数绑定（安全）
  • 返回影响行数（int）
  • 可读性强
  • 支持查询日志、事件监听

✅ 方案 2：原生语句 + 绑定（若必须用原生）

DB::statement(
    "DELETE FROM users WHERE created_at < ?", 
    ['2020-01-01']
);

• 优势：走 prepare() + execute()，安全
• 缺点：仍不如 Query Builder 语义清晰

✅ 方案 3：动态日期（安全示例）

$beforeDate = now()->subDays(30);
DB::table('users')->where('created_at', '<', $beforeDate)->delete();

五、Laravel 封装机制：为什么存在 statement()？

尽管有风险，statement() 仍有合法场景：

🛠️ 设计哲学：Laravel 不阻止危险操作，但提供安全默认路径，并将危险操作显式化（需开发者主动选择）。

六、生产环境建议

1. 禁止在业务逻辑中使用未绑定的 statement()

• 若必须用原生 SQL，强制要求 $bindings 非空
• 可通过 静态分析工具（如 PHPStan） 或 自定义 sniff（PHP_CodeSniffer） 检测

2. 获取影响行数

• DB::statement() 不返回行数！
• 改用 Query Builder 的 delete()：

  $count = DB::table('users')->where(...)->delete();
  Log::info("Deleted {$count} old users");
  

3. 事务包裹

• 大量删除操作应包裹在事务中：

  DB::transaction(function () {
      DB::table('users')->where('created_at', '<', '2020-01-01')->delete();
  });
  

4. 性能考量

• 删除大量数据时，分批处理避免锁表：

  while (DB::table('users')->where('created_at', '<', '2020-01-01')->limit(1000)->delete()) {
      // 继续直到删完
  }
  

七、总结：这行代码的“牛体解剖图”

🔪 庖丁之刀：
DB::statement() 不是“快捷方式”，而是“安全豁免通道”。
它的存在，是为了处理框架无法覆盖的边缘场景，而非日常 CRUD。
理解其底层执行机制与风险边界，方能在保持生产力的同时，守住安全底线。