PHP用mysqli执行DELETE语句前必须检查WHERE条件，否则会清空整张表；应先用SELECT验证、用预处理防注入、用事务保证一致性、优先软删除而非硬删除。
PHP用mysqli执行DELETE语句前必须检查WHERE条件
没加WHERE的DELETE FROM users会清空整张表，不是“删不掉”，而是“删得太干净”。这种误操作在开发环境可能只是重插测试数据，在生产环境就是事故。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 写完SQL先手动在phpMyAdmin或MySQL CLI里用
SELECT *验证WHERE是否命中预期记录 - 把
DELETE语句改成SELECT COUNT(*)先查数量，比如SELECT COUNT(*) FROM orders WHERE status = 'pending' AND created_at - 线上脚本务必加上
LIMIT 1（如DELETE FROM logs WHERE created_at ），避免单次锁表太久
PDO预处理删除时，参数绑定顺序和类型不能错
用PDO::prepare()和bindValue()看似安全，但bindValue(1, $id)如果$id是字符串而字段是INT，MySQL可能隐式转换失败，导致0行影响——你看到$pdo->rowCount() === 0，却以为数据不存在，实际是类型不匹配被过滤了。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 显式指定类型：
$stmt->bindValue(1, $id, PDO::PARAM_INT)，别依赖自动推断 - 执行后立刻检查
$stmt->rowCount()，等于0时不要直接返回成功，先echo $stmt->queryString和绑定值调试 - 避免用
bindParam()绑定变量引用，尤其在循环中——下一次迭代会覆盖上一次的值，导致所有DELETE都用最后一个ID
删除关联数据时，外键约束会让mysqli_query()直接报错
比如DELETE FROM categories WHERE id = 5，但products.category_id外键没设ON DELETE CASCADE，MySQL就扔出错误Cannot delete or update a parent row: a foreign key constraint fails。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 先查文档确认外键行为，建表时就决定好是
CASCADE、SET NULL还是RESTRICT - 需要手动清理时，按依赖顺序删：先
DELETE FROM products WHERE category_id = 5，再删categories本身 - 用事务包住多步删除：
$pdo->beginTransaction()→ 执行多条DELETE→$pdo->commit()，任一步失败就$pdo->rollback()
软删除比硬删除更适合多数业务场景
直接DELETE FROM users WHERE id = 123后，订单、日志、权限记录全断链，审计和恢复几乎不可能。真要删，优先考虑加deleted_at字段做标记。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 建表时就加
deleted_at TIMESTAMP NULL，查询统一加WHERE deleted_at IS NULL，删操作只改这个字段 - 用Eloquent等ORM时，直接开
SoftDeletestrait，$user->delete()自动转成UPDATE - 真要物理删除（比如GDPR用户彻底清除），单独写清理脚本，且必须带双人复核机制——没人该有单点执行
DROP TABLE的权限
真正难的不是写那行DELETE，是判断“到底该不该删”“删了之后谁还依赖它”“删错怎么回滚”。数据库不是垃圾桶，是活的数据关系网。
