触发器本身不占连接，但大事务会卡死数据库线程，导致连接无法释放、连接池耗尽；根本原因是其FOR EACH ROW同步阻塞执行，与DML共用事务上下文，批量操作时引发雪崩式资源争用。
触发器本身不占连接，但大事务会让数据库线程卡死，应用层不断重试获取连接，最终把连接池“撑爆”——这不是连接没还，是 MySQL 或 PostgreSQL 已经没响应能力了。
触发器执行卡在事务里，连接就永远不释放
触发器运行在 DML 所属的同一事务中，且是同步阻塞执行。比如一个 AFTER UPDATE 触发器里写了 10 行复杂 SQL（含子查询、多表 JOIN、写入审计日志表），整个 UPDATE 语句就必须等它全部跑完才能提交：
- 事务未提交 → 连接不能归还给连接池
- 高并发下，20 个并发 UPDATE 就会锁住 20 个连接，持续数秒甚至几十秒
- HikariCP 或 PgBouncer 看到连接长时间 active，pending 队列开始堆积
- 应用层超时后重试，新请求继续抢连接 → 恶性循环
FOR EACH ROW + 大批量操作 = 连接池雪崩加速器
触发器声明为 FOR EACH ROW 时，行为完全取决于 DML 影响行数。一条 UPDATE orders SET status = 'shipped' WHERE created_at > '2026-10-01' 更新 5 万行，就会让触发器执行 5 万次：
- 每次执行都复用同一个事务上下文，但每轮逻辑都要访问索引、写日志、查关联表
- MySQL 的
sp_head内存结构按触发次数分配，5 万次 ≈ 吃掉 100MiB+ 堆内存 - PostgreSQL 的
EXECUTE动态语句在循环中反复解析，CPU 占用飙升 - 连接池活跃数打满后，新请求要么排队（
pending增长），要么直接报错FATAL: remaining connection slots are reserved...
为什么加连接池大小反而更糟？
盲目调大 maximumPoolSize 或 max_connections 只是把压力从应用侧转移到数据库内核：
- MySQL 的线程数上限受
max_connections控制，但真实瓶颈是memory/sql/sp_head::main_mem_root和 CPU - PostgreSQL 中每个连接固定消耗约 10MB 内存，200 连接就是 2GB，再叠加触发器逻辑开销，OOM 风险陡增
- SQL Server 的
sp_OACreate在大量触发器并发调用时，会因 COM 对象争用导致线程挂起，WAITFOR DELAY类错误频发 - 真正有效的解法不是扩容，而是砍掉触发器里的非原子操作：把字段派生、状态更新等保留在触发器，把跨表写入、远程调用、复杂计算全移出
最常被忽略的一点：触发器是否真的需要 FOR EACH ROW？很多场景其实只需 FOR EACH STATEMENT（PostgreSQL 支持，MySQL 不支持），或干脆改用应用层批处理 + 事务控制——既可控，又可监控，还不拖垮数据库。别让“自动执行”的便利，掩盖了它对连接生命周期的绝对掌控力。
