触发器不能直接冻结账户，因其仅能抛出错误或写入标记表；真冻结须由外部服务读取信号后执行，否则账户状态仅停留在“逻辑标记”层面。
触发器不能直接冻结账户，只能抛出错误或写入标记表——真冻结必须由外部服务读取信号后执行，否则账户状态永远停留在“逻辑标记”层面。
为什么触发器里写UPDATE users SET status='frozen'是危险的
多数生产环境禁用触发器内修改其他表，尤其涉及核心账户表。MySQL 8.0+ 明确禁止在触发器中执行 UPDATE、INSERT 等非只读操作（报错 ERROR 1422）；PostgreSQL 虽允许，但会引发事务嵌套、锁等待甚至死锁——比如账户冻结逻辑又触发另一个审计触发器，形成链式阻塞。
更关键的是：冻结账户往往需同步停用会话、清空 token、通知风控系统，这些根本不是 SQL 能完成的事。
- 触发器内执行耗时操作（如调用
curl或发邮件）会卡住整个事务，导致写入延迟飙升 - 账户状态字段（如
status）若被多个触发器/应用并发更新，极易丢失状态变更 - 没有事务外补偿机制时，一旦冻结失败（如网络抖动），数据库里已写入“frozen”，但外围系统毫无感知
MySQL 中用触发器 + 队列表实现安全冻结
适用场景：无法改应用代码、需最小侵入式改造的旧系统。核心思路是把“冻结请求”当作消息写入轻量表，由外部脚本异步消费。
建一张专用队列表：alert_queue，字段包括 id、user_id、alert_type（值为 'account_frozen'）、created_at、processed（TINYINT 默认 0）。
在业务表（如 transactions）上建 BEFORE INSERT 触发器：
DELIMITER $$
CREATE TRIGGER freeze_on_risk BEFORE INSERT ON transactions
FOR EACH ROW
BEGIN
DECLARE risk_score DECIMAL(5,2) DEFAULT 0;
SELECT risk_score INTO risk_score FROM users WHERE id = NEW.user_id;
IF risk_score > 95 THEN
INSERT INTO alert_queue (user_id, alert_type, created_at)
VALUES (NEW.user_id, 'account_frozen', NOW());
END IF;
END$$
DELIMITER ;
注意点：
- 触发器里只做简单查询和单行插入，绝不调用函数或远程服务
-
alert_queue表必须用InnoDB引擎，并在created_at和processed上建联合索引：INDEX idx_unprocessed (processed, created_at) - 消费脚本每次只取前 100 条未处理记录，处理完再
UPDATE alert_queue SET processed=1 WHERE id IN (...)，避免长事务
PostgreSQL 中用 NOTIFY 实现毫秒级冻结通知
比轮询更轻量，适合同一实例内已有监听进程的架构。触发器不写表，直接发事件：
CREATE OR REPLACE FUNCTION notify_frozen_account()
RETURNS TRIGGER AS $$
BEGIN
PERFORM pg_notify('account_alerts',
json_build_object('user_id', NEW.user_id, 'reason', 'risk_threshold_exceeded')::text
);
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
绑定到表：
CREATE TRIGGER trigger_frozen_notify BEFORE INSERT ON transactions FOR EACH ROW WHEN (NEW.risk_score > 95) EXECUTE FUNCTION notify_frozen_account();
监听端用 psql 或应用代码长连接接收：
LISTEN account_alerts;
收到消息后，由监听进程调用风控 API 或执行 UPDATE users SET status='frozen' ...。优势是无轮询开销，延迟
-
NOTIFY不保证送达，连接断开期间消息丢失，关键业务必须加重试和幂等判断 - 监听进程需自行维护连接健康状态，建议用
pg_recvlogical或libpq的自动重连机制 - 不能跨数据库实例，若账户表和交易表在不同库，此法失效
最容易被忽略的是冻结后的状态同步——比如用户正在发起支付，触发器刚写完 alert_queue，但支付事务还没提交，此时冻结脚本查到记录并执行了 UPDATE，而支付仍可能成功扣款。真正健壮的做法，是在冻结前先对用户行加 SELECT ... FOR UPDATE 锁，或让冻结操作本身参与主事务（即由应用层统一控制）。触发器只是信号源，不是执行终点。
