逻辑删除还原失败主因是WHERE条件遗漏软删除字段，须同时校验主键与删除标记；跨库需注意字段类型差异及触发器干扰，还原前必须双重校验存在性与状态。
SQL Server 里用 UPDATE 恢复逻辑删除记录时，WHERE 条件漏掉软删除字段
逻辑删除还原失败，十次有八次是因为只写了 WHERE id = @id，却忘了加 AND is_deleted = 1。否则可能把一条本就正常的记录又“还原”一遍，或者更糟——误更新其他表的关联数据。
实操建议：
- 还原语句必须同时校验主键和删除标记，例如：
UPDATE users SET is_deleted = 0 WHERE id = @id AND is_deleted = 1 - 执行前先查一遍：
SELECT id, is_deleted FROM users WHERE id = @id，确认当前确实是已删除状态 - 在存储过程中加
IF @@ROWCOUNT = 0 BEGIN RAISERROR('记录不存在或未被逻辑删除', 16, 1) RETURN END防止静默失败
MySQL 存储过程中还原逻辑删除时，is_deleted 字段类型是 TINYINT(1) 还是 BIT？
类型不一致会导致条件永远不匹配。比如字段定义为 TINYINT(1) 存了 1，但你在 WHERE 里写 is_deleted = TRUE，MySQL 会把它转成 1 —— 看似没问题；但如果字段是 BIT(1)，TRUE 就可能变成二进制 b'1'，比较结果为 false。
实操建议：
- 用
DESCRIBE table_name查清字段真实类型，别信建表语句里的注释 - 统一用数值比较：
is_deleted = 1，而不是布尔字面量 - 如果字段是
ENUM('N','Y')或VARCHAR，还原语句必须匹配字符串值，比如is_deleted = 'Y'
PostgreSQL 中还原逻辑删除时，触发器或默认值干扰 UPDATE
有些表给 updated_at 加了 DEFAULT NOW() 或触发器自动更新时间戳，还原操作一执行，时间字段就被重置，丢失原始删除时间。更麻烦的是，如果触发器还顺手改了 status 或 version 字段，就不是单纯“还原”了。
实操建议：
- 还原前先禁用相关触发器：
SET session_replication_role = 'replica';（临时跳过触发器），完事再设回'origin' - 如果不能关触发器，就在
UPDATE里显式保留原值：updated_at = updated_at，避免被默认值覆盖 - 检查表上是否有
BEFORE UPDATE触发器修改了is_deleted以外的字段，这类逻辑必须在还原前评估是否要绕过
Oracle 存储过程还原逻辑删除，is_deleted 是 CHAR(1) 且存了空格
Oracle 对 CHAR 类型补空格，所以你看到的 '1' 实际可能是 '1 '（带空格）。用 WHERE is_deleted = '1' 查不到，还原自然失效。
实操建议：
- 用
RTRIM(is_deleted) = '1'或is_deleted LIKE '1%'更安全 - 建表时尽量避免用
CHAR存逻辑标记，改用NUMBER(1)或VARCHAR2(1) - 还原前加校验：
SELECT DUMP(is_deleted) FROM your_table WHERE id = :id，看实际字节内容
事情说清了就结束。最常被忽略的其实是还原前没做存在性+状态双重校验，以及跨数据库时对字段类型的想当然。
