sql触发器不能直接调用外部脚本，因数据库设计禁止事务内执行系统命令；可靠方案是触发器仅写入cleanup_queue表标记待处理任务，由外部脚本轮询并执行清理。
SQL触发器本身不能直接调用外部脚本
这是最关键的前提：所有主流关系型数据库（MySQL、PostgreSQL、SQL Server、Oracle）的原生触发器机制都运行在服务端隔离环境中，BEFORE DELETE 或 AFTER DELETE 触发器内部**无法执行系统命令、启动进程或调用 shell 脚本**。试图在触发器里写 SYSTEM 'rm -rf /tmp/data' 或 EXEC xp_cmdshell 会报错或被默认禁用——不是语法不对，而是设计上就不允许。
常见错误现象包括：ERROR 1370 (42000): execute command denied to user（MySQL）、permission denied for function dblink_connect（PostgreSQL 配合扩展时权限不足）、SQL Server 中 xp_cmdshell 默认关闭且需高权限启用。
- 触发器是事务内执行的，外部脚本若失败或阻塞，会导致整个删除事务回滚或超时，破坏数据一致性
- 数据库进程通常以低权限用户运行（如
mysql、postgres），无权访问应用目录或执行敏感操作 - 跨平台不可移植：同一套触发器逻辑在 Linux 和 Windows 上无法通用
推荐方案：触发器写标记 + 外部轮询监听
真正可行的做法是把“触发”拆成两步：数据库只负责记录「该清理了」，由外部程序主动发现并执行清理。这避免了权限、事务、阻塞等硬约束。
典型实现路径：
- 建一张轻量级通知表，例如
cleanup_queue，含字段：id（自增）、table_name、row_id、status（'pending'/'done'）、created_at - 在目标表的
AFTER DELETE触发器中，仅执行INSERT INTO cleanup_queue (...) VALUES (...)，不带复杂逻辑 - 用独立脚本（Python/Node.js/shell）定时查
SELECT * FROM cleanup_queue WHERE status = 'pending'，处理后更新status = 'done'
示例（PostgreSQL）：
CREATE OR REPLACE FUNCTION notify_for_cleanup()
RETURNS TRIGGER AS $$
BEGIN
INSERT INTO cleanup_queue (table_name, row_id, created_at)
VALUES ('users', OLD.id, NOW());
RETURN OLD;
END;
$$ LANGUAGE plpgsql;
<p>CREATE TRIGGER users_after_delete
AFTER DELETE ON users
FOR EACH ROW
EXECUTE FUNCTION notify_for_cleanup();
</p>
替代方案对比：哪些能用？哪些要避开？
有人尝试用数据库扩展或外部函数绕过限制，但实际落地成本高、风险大：
-
pg_notify()+ LISTEN（PostgreSQL）：可行，但监听端必须长连接且可靠重连，不适合一次性清理任务 - MySQL UDF（User Defined Function）：需编译 C 插件，DBA 通常禁止加载，版本升级易失效
- SQL Server 的 CLR 集成：需开启
TRUSTWORTHY，违反最小权限原则，审计难通过 - 物化视图或定时 JOB（如 pg_cron）：适合周期性批量清理，不响应单次删除事件
真正稳定的边界是：数据库只管状态，外部程序管执行。哪怕多一次查询延迟（毫秒级），也比触发器卡死整个事务强。
清理脚本如何安全获取上下文？
触发器插入 cleanup_queue 时，应尽量提供足够信息让外部脚本明确「清什么」，但避免存敏感内容：
- 必填字段：源表名（
table_name）、主键值（row_id）、时间戳（created_at） - 可选字段：操作类型（
action= 'delete'）、关联资源标识（如file_path_pattern，但不要存绝对路径） - 脚本读取时加
FOR UPDATE SKIP LOCKED（PostgreSQL）或SELECT ... FOR UPDATE（MySQL），防止并发重复处理 - 务必设置 TTL 清理：定期删掉
status = 'done'且超过 1 小时的记录，防表膨胀
别指望触发器传一堆 JSON 过去——它只是信使，不是搬运工。真正复杂的路径拼接、权限校验、重试逻辑，全得放在外部脚本里做。
最常被忽略的一点：cleanup_queue 表必须有索引，至少在 (status, created_at) 上建复合索引，否则轮询查询会随着数据增长越来越慢。
