软删除应避免用is_deleted布尔型字段，推荐status枚举（'active'/'deleted'/'archived'）+deleted_at时间戳；status设NOT NULL DEFAULT 'active'，deleted_at用DATETIME类型；触发器监听UPDATE，用OLD.status='active' AND NEW.status='deleted'精准判断，归档表需显式列字段、去主键、增archived_at、status写死为'archived'。
软删除字段命名和基础表结构怎么设才不踩坑
软删除不是真删，而是用字段标记“已删除”状态。最常见错误是用 is_deleted 布尔型字段——它无法区分“从未删除”“已软删”“已归档”三种状态。更稳妥的做法是用 status 字符串或枚举类型，值为 'active'、'deleted'、'archived'。同时必须加 deleted_at 时间戳字段，否则后续归档逻辑无法判断软删发生时间。
-
status字段建议设为NOT NULL DEFAULT 'active'，避免空值干扰触发器判断 -
deleted_at字段类型用TIMESTAMP WITH TIME ZONE（PostgreSQL）或DATETIME（MySQL），别用DATE，精度不够 - 如果已有表，先补全字段再建触发器，否则触发器里读不到
deleted_at会报column does not exist错误
触发器里怎么捕获 UPDATE 并识别软删除动作
触发器必须监听 UPDATE，而不是 DELETE ——因为软删除本质是改状态，不是发 DELETE 语句。关键在于：只在 status 从 'active' 变为 'deleted' 时触发归档，其他变更（比如编辑内容但 status 不变）不能连带归档。
- PostgreSQL 示例中，用
OLD.status = 'active' AND NEW.status = 'deleted'做条件判断，不能只写NEW.status = 'deleted'，否则重复更新会多次归档 - MySQL 的
BEFORE UPDATE触发器里，OLD和NEW是可用的，但注意不能在BEFORE里对本表做 INSERT（会递归触发），归档操作必须放AFTER UPDATE - SQLite 不支持
AFTER UPDATE触发器对本库其他表写入，若用 SQLite，得改用应用层补偿或定时任务
归档表结构和 INSERT INTO ... SELECT 怎么写才安全
归档表不是原表简单复制。它应该去掉主键约束（归档后不再更新）、增加 archived_at 字段、并把 status 固定为 'archived'。用 INSERT INTO archive_table SELECT ... FROM original_table 时，必须显式列出所有字段，不能用 * ——否则原表加字段会导致归档失败或错位。
- 归档表的
id字段建议保留，但取消PRIMARY KEY或改为普通索引；新增archived_at用CURRENT_TIMESTAMP填充 -
SELECT子句里，把status写死为'archived'，deleted_at保持原值，archived_at用函数生成，例如 PostgreSQL 写NOW()，MySQL 写NOW()或CURRENT_TIMESTAMP - 如果原表有外键，归档表不要加外键约束——归档后关联数据可能已被删，强制校验反而导致插入失败
为什么不能在触发器里加事务控制或异常捕获
很多人想在触发器里套 BEGIN ... EXCEPTION（PostgreSQL）或 DECLARE EXIT HANDLER（MySQL）来兜底，这反而会让问题更隐蔽。触发器运行在父事务上下文中，一旦出错，整个 UPDATE 会被回滚，用户看到的是“更新失败”，但根本不知道是归档环节崩了。
- 触发器内禁止调用存储过程做复杂逻辑，尤其是涉及网络请求、文件写入或跨库操作——这些不可控因素会拖慢主业务链路
- 真要容错，应该把归档动作解耦成异步任务（如发消息到 Kafka / RabbitMQ），触发器只负责发信号；同步触发器只做轻量级、确定性高的操作
- 测试时务必用
EXPLAIN ANALYZE（PostgreSQL）或EXPLAIN FORMAT=TREE（MySQL 8.0+）看触发器是否引入全表扫描——如果归档语句没走索引，大表上一次软删除就卡住整个库
归档逻辑越靠近数据层，越要警惕它的副作用。一个没设索引的 WHERE deleted_at IS NOT NULL，或者触发器里漏掉 AND status = 'deleted' 条件，都可能让归档表越积越多却查不出来。
