执行后查ROW_COUNT()或等效函数是最直接判断依据：MySQL用ROW_COUNT()，PostgreSQL用GET DIAGNOSTICS或RETURNING子句，SQL Server用@@ROWCOUNT，Oracle用SQL%ROWCOUNT；必须紧跟DML语句后立即获取，且需结合SELECT验证WHERE条件、事务状态和业务上下文综合判断。
执行后查ROW_COUNT()或等效函数
大多数数据库在DELETE执行完会返回“影响行数”，这是最直接的判断依据。MySQL用ROW_COUNT()，PostgreSQL用GET DIAGNOSTICS或RETURNING子句，SQL Server用@@ROWCOUNT，Oracle用SQL%ROWCOUNT。别依赖客户端返回的“Query OK”这种模糊提示——它只表示语句没语法错误，不表示删到了东西。
- MySQL里执行完
DELETE，立刻跟一句SELECT ROW_COUNT();，返回0就说明WHERE条件没匹配到任何行 - PostgreSQL推荐用
DELETE ... RETURNING *，既能确认删了哪些行，又能拿到被删数据快照，比单纯看行数更可靠 - SQL Server中
@@ROWCOUNT必须紧跟在DELETE之后——中间插一条PRINT或SELECT都会让它失效
先用SELECT验证WHERE条件是否有效
这是防误删的第一道防线，但很多人跳过这步。你写的WHERE条件可能因为字段类型隐式转换、NULL值比较、索引失效等原因完全不生效。比如WHERE status = 'active'在status字段是TEXT且含不可见空格时，可能一条都匹配不到。
- 把
DELETE里的WHERE子句原样复制，套进SELECT COUNT(*)或SELECT *里先跑一遍 - 特别注意
NULL：用IS NULL而不是= NULL，否则SELECT也查不到，DELETE自然不生效 - 如果表有分区或物化视图，确认
WHERE条件能命中实际数据所在的分区，否则SELECT和DELETE都可能返回0
警惕事务未提交导致“看似没删成”
在支持事务的引擎（如InnoDB、PG）里，DELETE执行后若没COMMIT，其他会话查不到变化，你自己再SELECT也看不到效果——容易误判为“没删成功”。但这不是DELETE本身失败，而是隔离级别和事务状态造成的假象。
- 开发/测试阶段习惯加
BEGIN TRANSACTION和ROLLBACK来试删，但别忘了最后真正执行时要换COMMIT - 某些ORM或连接池默认开启自动提交（autocommit），有些则关闭，行为不一致；检查你用的驱动文档，确认当前连接的实际提交模式
- 用命令行客户端执行时，留意提示符是否还显示
mysql>（已提交）还是...>（等待分号，事务未结束）
DELETE返回0行不等于出错，但可能是业务逻辑断点
有时候你期望删掉10条，结果ROW_COUNT()返回0，程序却没报错也没告警——这往往暴露的是上游数据状态异常，比如定时任务重复触发、状态机流转错误、或者缓存与DB不一致。不能只盯着SQL是否“执行成功”，得结合业务上下文判断“没删到”是否合理。
- 日志里记下
WHERE条件原文和ROW_COUNT()结果，方便事后回溯：是条件写错了？数据早被别人删了？还是根本没这条数据？ - 对关键删除操作（如清退用户、归档订单），建议在应用层做二次校验：删完再
SELECT一次，确认目标记录确实不存在 - 避免在存储过程中只靠
IF ROW_COUNT() = 0 THEN ...做分支，而忽略为什么为0——是预期中的空操作，还是需要告警的数据异常？
真实场景里，最麻烦的不是删多了，而是删了等于没删：条件无效、事务卡住、或返回值被忽略。盯住ROW_COUNT()，坚持SELECT先行，再确认事务状态，才能把“删没删成”这件事真正闭环。
