最常见且最危险的误操作是在DELETE触发器中漏写WHERE条件，导致全表删除；此外还存在OLD不可用、多行删除漏测、外键匹配错误、软删除忽略、嵌套循环、日志缺失及长期隐患等问题。
触发器里写了 DELETE 却没加 WHERE 条件
这是最常见也最危险的误操作：在 BEFORE DELETE 或 AFTER DELETE 触发器中，用 DELETE FROM 关联表 但漏掉 WHERE 子句，结果删光整张表。
比如原意是删掉订单后同步清空该订单的明细，却写成：
DELETE FROM order_items;
而不是：
DELETE FROM order_items WHERE order_id = OLD.id;
- MySQL / PostgreSQL 都不会报错，语句合法，但后果严重
- 触发器执行时
OLD（或OLD.*）只在行级触发器中可用；如果定义成语句级（FOR EACH STATEMENT），OLD根本不可用，此时连变量都取不到，更别说条件了 - 测试时容易漏掉多行删除场景——单条记录测试正常，批量
DELETE FROM orders WHERE status = 'canceled'就崩
ON DELETE CASCADE 没开，但触发器手动模拟时逻辑错位
有些同学想“手动控制”级联删除过程，于是关掉外键的 ON DELETE CASCADE，改用触发器实现。但容易忽略事务边界和主键匹配精度。
典型错误是拿错关联字段，比如：
- 订单表用
order_no（字符串）当主键，触发器里却按id（自增整数）去查子表，导致查不到、删不掉，或误删其他行 - 子表有复合外键（如
(order_id, item_seq)），触发器只用order_id做条件，删掉不该删的项 - 没考虑软删除场景：主表只是把
deleted_at设为非空，但触发器仍按硬删除逻辑清空子表
触发器嵌套删除引发循环或遗漏
当 A 表触发器删 B 表，B 表也有触发器删 C 表，而 C 表反过来又影响 A 表（比如更新 A 的统计字段），就可能触发嵌套甚至死循环。MySQL 默认限制嵌套深度为 25，PostgreSQL 可设 session_replication_role 控制，但不是根本解法。
- 先确认是否真需要多层触发：多数情况下，用应用层事务或物化视图比层层触发更可控
- 如果必须保留，务必在每层触发器开头加守卫判断，例如：
IF NOT EXISTS (SELECT 1 FROM pg_trigger WHERE tgname = 'prevent_nested') THEN ...（PostgreSQL）或用会话变量标记 - 特别注意 MySQL 的
SQL_LOG_BIN = 0在复制环境下的副作用——它会让触发器操作不写 binlog，从库数据就不同步
没验证触发器是否真被调用
删完数据发现关联表空了，但不确定是触发器干的、还是应用代码干的、还是某人手抖执行了全表删。这时候得靠证据定位。
- 查触发器是否启用：
SHOW TRIGGERS LIKE 'orders'（MySQL）或\df+ trigger_name（PostgreSQL）看Enabled状态 - 临时加日志：MySQL 可写入
mysql.general_log（需开启），PostgreSQL 可用RAISE NOTICE+log_min_messages = notice - 用
EXPLAIN ANALYZE DELETE FROM orders WHERE id = 123看执行计划里有没有触发器相关提示（部分版本支持） - 最稳妥的是在触发器第一行加
INSERT INTO debug_log VALUES (NOW(), 'orders_del', OLD.id)，再查日志表确认执行路径
真正麻烦的不是写错触发器，而是它静默运行多年，直到某次数据迁移或字段重构，才突然暴露出条件失效、类型隐式转换、或 NULL 处理异常——这些细节在日常 DML 中几乎不暴露，一出事就是批量丢数据。
