mysql中delete触发器无法跨库归档，因before阶段old不可用于select、after阶段跨库insert被禁止且易致error 1442；应改用异步方案：触发器仅写delete_log表，由外部任务消费并归档。
直接在 DELETE 触发器里写 INSERT INTO archive_db.table SELECT ... 是行不通的——跨库操作在多数 MySQL 版本中受限，且触发器内不能有显式事务控制或非确定性函数，更别说归档逻辑出错会导致原删除失败。
MySQL 中 BEFORE DELETE 触发器无法跨库 INSERT
MySQL 的触发器作用域默认锁定在当前数据库，INSERT INTO archive_db.orders 这类语句在 5.7 及以前会直接报错 ERROR 1442 (HY000): Can't update table 'orders' in stored function/trigger because it is already used by statement which invoked this stored function/trigger（即使目标表不同，跨库写入也会被引擎拒绝）。8.0 虽放宽部分限制，但依然禁止在触发器中对其他库执行 DML 作为“副作用”。
- 触发器本质是语句原子的一部分，MySQL 要求所有操作可回滚，而跨库写入破坏了这个保证
-
archive_db若为远程库（如通过 FEDERATED 或 MySQL Router），触发器根本无法建立连接 - 哪怕用
INSERT INTO archive_db.table SELECT ... FROM OLD语法，也会因OLD在BEFORE阶段不可用于SELECT子句而报错
用 AFTER DELETE + 事件轮询替代实时归档
把归档动作从触发器里剥离出来，改由外部轻量服务或定时任务承接，才是稳定可行的路径。核心思路：用一张本地 delete_log 表记录待归档的主键，再由独立进程消费它。
- 先建日志表：
CREATE TABLE delete_log (id BIGINT PRIMARY KEY AUTO_INCREMENT, table_name VARCHAR(64), pk_value VARCHAR(255), deleted_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP) - 在业务库建
AFTER DELETE触发器，只做最小动作：INSERT INTO delete_log (table_name, pk_value) VALUES ('orders', OLD.order_id)（注意：OLD.order_id必须是主键或唯一标识字段） - 用 Python 脚本或 crontab 每 30 秒查一次
delete_log WHERE processed = 0，取出记录 → 查询原表历史快照（需提前开启 binlog 或保留软删除字段）→ 写入归档库 → 更新processed = 1
这样解耦后，删除主流程不依赖归档成功与否，也不会因归档库慢或挂掉而阻塞业务。
PostgreSQL 可用 dblink 实现有限跨库写入
如果必须在数据库层完成，PostgreSQL 提供 dblink 扩展，允许触发器内发起远程连接并插入。但它有硬伤：
- 需手动安装扩展：
CREATE EXTENSION dblink，且连接串密码明文写在触发器里（不推荐） - 一旦归档库不可达，
dblink_exec()抛异常 → 整个DELETE失败，违背归档“尽力而为”的设计初衷 - 示例片段：
PERFORM dblink_exec('host=archive-db port=5432 dbname=archive', 'INSERT INTO orders_archive SELECT * FROM orders WHERE id = ' || OLD.id)
实际生产中，仍建议用异步消息队列（如 Kafka）或 WAL 解析（如 Debezium）替代，避免把归档逻辑钉死在数据库内部。
真正难的不是“怎么写那几行 INSERT”，而是接受“触发器不该承担归档责任”这个事实——它太脆弱，也太重。归档的本质是异步、可重试、可监控的数据搬运，这些特性跟触发器的同步强一致性模型天然冲突。
