delete语句必须带where条件，否则会清空整张表；应使用pdo预处理或mysqli绑定参数防注入，并用select count(*)预查、rowcount()验证影响行数。
PHP 中用 DELETE 语句必须带 WHERE
不加 WHERE 条件的 DELETE FROM users 会清空整张表，且无法回滚（除非有备份或事务支持）。PHP 本身不校验 SQL 逻辑，它只负责把字符串发给数据库。所以「加限制」不是 PHP 的功能，而是你写 SQL 时的硬性责任。
常见错误现象：mysqli_query($conn, "DELETE FROM logs") 执行后发现日志全没了；或者拼接 WHERE 时变量为空，导致实际执行的是 DELETE FROM logs WHERE id = '' —— 某些 MySQL 配置下这仍可能误删多行（比如 id 是字符串类型且允许空值）。
- 永远在
DELETE后显式写WHERE，哪怕只是WHERE 1=0用于占位调试 - 避免直接拼接用户输入：用
mysqli_prepare()或 PDO 预处理，防止 SQL 注入同时强制参数绑定 - 上线前用
SELECT COUNT(*)先查匹配行数，确认范围再删
PDO 预处理删除：安全又明确
PDO 是目前推荐方式，预处理能隔离 SQL 结构和数据，天然防注入，也强制你思考「删哪些」。
$pdo = new PDO("mysql:host=localhost;dbname=test", $user, $pass);
$stmt = $pdo->prepare("DELETE FROM comments WHERE post_id = ? AND status = ?");
$stmt->execute([$_GET['post'], 'spam']);
注意点：
立即学习“PHP免费学习笔记（深入）”；
- 问号占位符数量必须和
execute()数组元素严格一致，否则报错SQLSTATE[HY093] - 如果条件字段可能为
NULL，别用= ?，改用IS ?或分开判断（IS NULL不能用=） - 执行后可用
$stmt->rowCount()检查实际影响行数，为 0 说明没删到，可能是条件不匹配
MySQLi 面向对象方式：别漏掉 bind_param
mysqli 也能做到安全，但容易漏掉绑定步骤，导致还是拼接字符串。
$mysqli = new mysqli("localhost", $user, $pass, "test");
$stmt = $mysqli->prepare("DELETE FROM orders WHERE user_id = ? AND created_at < ?");
$stmt->bind_param("is", $uid, $cutoff);
$uid = $_SESSION['id'];
$cutoff = date('Y-m-d', strtotime('-30 days'));
$stmt->execute();
关键细节：
-
bind_param("is", ...)第一个参数是类型字符串：i整型、s字符串、d浮点、bBLOB；类型错会导致静默失败或数据截断 - 变量必须在
bind_param前赋值，且不能是表达式（如date(...)要先存到变量里） - 如果条件有多个 OR 分支（如删状态为 A 或 B 的记录），确保括号和逻辑清晰：
WHERE (status = ? OR status = ?)
误删补救和防御性习惯
没有「后悔键」，但可以降低风险。线上环境别依赖人工恢复，重点放在预防。
- 开发/测试库开启
sql_safe_updates=1（MySQL），这样没WHERE或没用主键/索引字段的DELETE会被拒绝 - 敏感操作加二次确认：比如后台删除按钮点击后弹窗显示「将删除 7 条用户反馈记录，确定吗？」，数字来自前置
SELECT COUNT(*) - 所有删除操作记日志：记录时间、操作人、SQL 模板、绑定参数（脱敏手机号/邮箱）、影响行数
- 定期导出关键表快照（如每天凌晨），比指望 binlog 恢复更可控
最常被忽略的一点：WHERE 条件里用了函数（如 WHERE DATE(created_at) = '2024-01-01'）会导致索引失效，删得慢还可能锁表；优先改用范围查询 WHERE created_at >= '2024-01-01' AND created_at 。
