select验证是防止误删的唯一防线，必须先用count(*)确认删除量级、用具体字段limit 10核对业务逻辑、用explain检查字段类型与索引匹配性。
SELECT验证不是多此一举，是防止误删的唯一防线
直接执行 DELETE FROM users WHERE status = 'inactive' 等价于闭眼踩油门——你根本不知道它会删掉 3 行、3000 行，还是整个表。真实事故里，80% 的“删库跑路”不是恶意操作，而是 WHERE 条件写错、字段类型隐式转换、时区偏差或跨库连错导致的误匹配。先 SELECT 不是为了走流程，是用最小成本暴露这些漏洞。
WHERE条件验证必须覆盖这四个具体点
只跑 SELECT * 不够，容易漏掉关键陷阱：
-
SELECT COUNT(*)和SELECT id, updated_at, status LIMIT 10必须都做：前者确认量级（比如预期删 500 行，结果返回 50000，立刻停手）；后者人工核对时间范围、状态值是否真符合业务定义（比如status = 'inactive'是否包含刚注册未激活的用户？） - 检查字段类型和索引：
EXPLAIN SELECT * FROM users WHERE status = 'inactive' AND created_at ，确认 <code>created_at是DATETIME还是TIMESTAMP，是否用了时区转换函数（如CONVERT_TZ），避免因时区导致删多或删少 - 验证模糊匹配的安全性：如果条件含
LIKE '%keyword%'或正则，先用SELECT id, name FROM users WHERE name REGEXP '^[a-zA-Z]{2,20}$'检查是否意外匹配了空值、NULL 或超长乱码 - 确认关联子查询的上下文：例如
DELETE FROM orders WHERE user_id IN (SELECT id FROM users WHERE is_deleted = 1)，必须单独执行子查询，看它返回的id是否真在orders表中存在，且没被其他事务中途修改
软删/脱敏和硬删不能混着用
有人想“先脱敏再删”，这是危险误区。脱敏（如 UPDATE users SET phone = CONCAT(LEFT(phone,3), '****', RIGHT(phone,4))）改的是原表数据，而删除操作依赖的是脱敏后的值做判断——一旦脱敏逻辑有缺陷（比如没处理 NULL 或格式异常的手机号），WHERE phone LIKE '138****%' 就可能完全失效。更糟的是，脱敏本身不可逆，删完才发现脱敏漏了字段，已无从恢复原始数据。
真正安全的做法是：脱敏和删除走两条隔离路径。脱敏操作必须基于快照表（如 users_20260607_snapshot），并记录每行的原始 phone 值到日志表；删除则始终基于原始未脱敏表，用明确主键或业务唯一键（如 user_id）定位，不依赖任何脱敏后生成的字段值。
生产环境 DELETE 必须带事务 + LIMIT + 备份
即使 SELECT 验证通过，也不能裸删：
- 所有
DELETE必须包裹在START TRANSACTION中，执行后立刻查ROW_COUNT()，影响行数异常就ROLLBACK - 单次操作超过 1000 行，必须加
LIMIT 1000分批，并在循环中检查每次ROW_COUNT()是否为预期值（防止某批删完后条件不再命中） - 删除前必须导出原始数据：
SELECT * INTO OUTFILE '/tmp/delete_users_20260607.csv' FROM users WHERE ...，或用mysqldump --where="..."生成可读备份，保留至少 7 天 - 禁止在开启了
AUTOCOMMIT=1的会话中执行，MySQL 默认开启，务必先SET AUTOCOMMIT = 0
最常被忽略的一点：验证用的 SELECT 和后续 DELETE 必须在同一个事务里加锁（如 SELECT ... FOR UPDATE），否则中间可能有其他写入改变数据状态——尤其在高并发更新用户状态的场景下，status = 'inactive' 这个条件本身就不稳定。
