安全删除必须先用SELECT验证WHERE条件，确保数量合理、主键可见、关联可控；再用显式事务+行数校验；大表需分批按主键范围删除；外键依赖须提前检查；复杂场景优先软删除。
不加 WHERE 的 DELETE 在生产库上等同于主动触发 P0 级事故，不是“可能出错”，而是“必然出错”。 安全不是靠写得快、记得牢，是靠可验证的步骤闭环和数据库底层行为的清醒认知。
先用 SELECT 把要删的行“抓出来看一眼”
这是所有安全删除动作的起点，不是可选项。你写的 WHERE 条件在 SELECT 里跑一遍，结果必须满足三个硬指标：数量合理、主键可见、关联数据可控。
- 别只跑
SELECT COUNT(*)—— 它告诉你“有多少”，但不告诉你“是谁”。至少补一句SELECT id, created_at, status FROM ... LIMIT 5，确认字段值、NULL 情况、时间格式是否符合预期 - 涉及函数（如
DATE(created_at)）或类型转换（如字符串 ID 和数字比较）时，SELECT和DELETE实际影响行数可能不一致，必须用相同表达式执行 - 如果条件含
IN (subquery)，先单独执行子查询，检查返回值是否为空、是否超长、是否含 NULL（IN遇到 NULL 会整体失效） - 对时间字段，统一用标准格式（如
'2024-01-01 00:00:00'），避免依赖隐式转换；必要时用STR_TO_DATE()或CAST()显式处理
显式事务 + 行数校验是唯一靠谱的“后悔药”
自动提交关不关都没用，关键是你得有意识地控制提交时机，并在提交前确认影响行数是否在预估范围内。
- MySQL / PostgreSQL：开头写
BEGIN;，删完立刻跟SELECT ROW_COUNT();（MySQL）或GET DIAGNOSTICS ROW_COUNT（PG） - SQL Server：用
BEGIN TRAN;，删完查SELECT @@ROWCOUNT;，注意它只对上一条语句有效，中间不能插其他语句 - 如果返回行数为 0，检查
WHERE是否写错字段名、大小写、排序规则（如utf8mb4_0900_as_cs区分大小写） - 如果远超预期（比如预估删 200 行，实际返回 12 万），立刻
ROLLBACK;，别犹豫、别查日志、别问为什么——先保数据
大表删数据必须分批，且不能只靠 LIMIT
单次删几万行以上，会锁表、撑爆事务日志、拖垮整个实例。但 LIMIT 不是银弹，它本身就有隐患。
- MySQL 支持
DELETE ... LIMIT N，但必须配合ORDER BY id，否则删哪 N 行不可控；并发写入下多次执行可能删重或漏删 - PostgreSQL 不支持
LIMIT在DELETE中，得用ctid或 CTE 分页，例如：WITH batch AS (SELECT ctid FROM huge_table WHERE processed = 0 LIMIT 1000) DELETE FROM huge_table WHERE ctid IN (SELECT ctid FROM batch) - 更稳的做法是按主键范围删：
DELETE FROM huge_table WHERE id BETWEEN 10000 AND 10999 AND processed = 0，可重试、可监控、可跳过已处理段 - 每批之间加延迟（MySQL 用
SLEEP(0.1)，SQL Server 用WAITFOR DELAY '00:00:00.1'），缓解 I/O 压力
外键约束和 JOIN 删除必须提前查清依赖关系
你以为删的是 users 表里一行，其实数据库正在默默检查 orders、addresses、logs 至少 4 张表有没有挂着这个 user_id。没处理好，要么报错中断，要么级联删掉你根本没意识到的数据。
- 先查外键：MySQL 用
SELECT CONSTRAINT_NAME, TABLE_NAME, COLUMN_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'users';；SQL Server 用SELECT OBJECT_NAME(f.parent_object_id) AS table_name, COL_NAME(fc.parent_object_id, fc.parent_column_id) AS column_name FROM sys.foreign_keys AS f INNER JOIN sys.foreign_key_columns AS fc ON f.object_id = fc.constraint_object_id WHERE f.referenced_object_id = OBJECT_ID('users'); - 如果要连带删子表数据，优先用
JOIN（MySQL）或 CTE（PG/SQL Server），而不是子查询——前者执行计划稳定，且能用SELECT提前验证结果集 - 级联删除（
ON DELETE CASCADE）看起来省事，但生产环境慎用：它绕过应用层逻辑，无法审计、无法打点、无法熔断 - 真正复杂场景（如跨库、多级引用），建议改用软删除（
is_deleted = 1）+ 异步归档，把“删”变成“标记+搬运”
最常被跳过的其实是第一步：用 SELECT 查数据时，人眼扫过去就以为“没问题”。实际上，字段值是否含不可见字符、时间是否跨了夏令时、状态字段是否用了不同枚举值命名（比如前端传 "inactive"，数据库存 "archived"），这些细节只有真正把数据拉出来看才能暴露。安全删除不是技术问题，是注意力管理问题。
