Laravel原生update语句无法将NULL设为null数据类型的问题

1. 原生SQL拼接的问题根源 #

你用原生SQL拼接时，当$delete_date为null，手动处理引号的逻辑会把null转成空字符串，最终生成SET DeletedDate = ''的SQL片段。而数据库的datetime类型字段会把空字符串自动转换为该类型的默认值（也就是1900-01-01 00:00:00.000），这就导致了恢复操作不符合预期。

哪怕用DB::raw()或DB::statement，只要是手动拼接字符串，就会陷入两难：给值统一加引号的话，null会变成空字符串；不加引号的话，日期字符串又会触发SQL语法错误，根本没法同时适配两种场景。

2. Laravel查询构造器的自动处理逻辑 #

Laravel查询构造器采用参数绑定机制处理变量，它会自动识别值的类型并生成符合SQL语法的语句：

• 当$delete_date是日期字符串时，构造器会自动给值添加引号，生成合法的日期赋值语句；
• 当$delete_date是null时，构造器会直接生成SET DeletedDate = NULL的片段，完全遵循SQL对null的语法要求，不会转换成空字符串。

举个实际执行的例子：

// 删除操作，$delete_date为当前日期字符串
DB::table('your_table')->where('id', $id)->update(['DeletedDate' => $delete_date]);
// 生成的SQL：UPDATE your_table SET DeletedDate = '2024-05-20 14:30:00' WHERE id = ?

// 恢复操作，$delete_date为null
DB::table('your_table')->where('id', $id)->update(['DeletedDate' => $delete_date]);
// 生成的SQL：UPDATE your_table SET DeletedDate = NULL WHERE id = ?

这种机制不仅解决了类型适配问题，还能避免SQL注入风险，也是Laravel推荐使用查询构造器或ORM的核心原因之一。

3. 原生SQL的正确写法（若需坚持使用） #

如果一定要用原生SQL，别手动拼接值，改用参数绑定让Laravel帮你处理类型：

$id = 1;
$delete_date = null; // 或日期字符串

if (is_null($delete_date)) {
    $sql = "UPDATE your_table SET DeletedDate = NULL WHERE id = ?";
    DB::connection()->update($sql, [$id]);
} else {
    $sql = "UPDATE your_table SET DeletedDate = ? WHERE id = ?";
    DB::connection()->update($sql, [$delete_date, $id]);
}

内容的提问来源于stack exchange，提问作者Keyboard Corporation