必须加条件、验证和事务才能执行DELETE——禁止无WHERE删除，优先软删除，硬删除需事务+行数校验+异步审批。
直接执行 DELETE 语句极大概率导致误删且无法恢复——必须加条件、加验证、加事务，否则别碰生产库。
WHERE 条件缺失或写错是最高频的删库事故源头
MySQL 和 PostgreSQL 等主流数据库中，DELETE FROM users; 这种不带 WHERE 的语句会清空整张表，且不经过回收站。PHP 中用 mysqli_query() 或 PDO::exec() 执行时，不会二次确认。
- 永远显式写出
WHERE，哪怕只是WHERE id = ? - 禁止拼接变量进 SQL 字符串：
"DELETE FROM logs WHERE created_at —— 一旦$date为空或含单引号，可能变*表删除或语法错误 - 必须用预处理语句绑定参数：
$stmt = $pdo->prepare("DELETE FROM orders WHERE status = ? AND updated_at - 执行前可先用相同条件查一遍：
SELECT COUNT(*) FROM ...，确认影响行数在预期范围内（比如 ≤100）
没开事务就删数据，出错后根本回滚不了
PHP 默认关闭自动事务，DELETE 一执行就永久生效。尤其涉及多表关联删除（如先删订单再删订单项）时，中间出错会导致数据不一致。
- 用
$pdo->beginTransaction()显式开启事务 - 所有相关
DELETE操作放在try块里 - 成功则
$pdo->commit()，失败则$pdo->rollback() - 注意：MyISAM 表不支持事务，必须用 InnoDB 引擎
软删除比硬删除更适合多数业务场景
真正“删除”数据在绝大多数 Web 应用中是反模式。用户说“删评论”，实际只需标记为不可见；后台要清理历史日志，也应走归档+定时任务，而非 DELETE。
- 加字段如
is_deleted TINYINT(1) DEFAULT 0或deleted_at DATETIME NULL - 所有查询默认加
WHERE deleted_at IS NULL（可用视图或 ORM 范围作用域统一处理） - 真要物理删除时，也建议走异步任务 + 审批流程，而不是前端点一下就触发
- 硬删除只保留在极少数场景：临时测试数据、已归档冷数据、GDPR 用户注销后的合规擦除（且需留审计日志）
$pdo->beginTransaction();
try {
$stmt = $pdo->prepare("DELETE FROM order_items WHERE order_id = ?");
$stmt->execute([$order_id]);
$stmt = $pdo->prepare("DELETE FROM orders WHERE id = ?");
$stmt->execute([$order_id]);
$pdo->commit();
} catch (Exception $e) {
$pdo->rollback();
throw $e;
}
最常被忽略的一点：哪怕用了预处理和事务，如果没检查 $stmt->rowCount() 返回值，仍可能对 0 行生效却误以为删除成功——比如条件写成 WHERE id = 0，而主键从 1 开始。删之前查总数，删之后查影响行数，两头都对得上才算真正安全。
