max_execution_time对触发器内select无效，因其仅约束独立执行的select语句；触发器中select因嵌套在事务内同步执行，且可能引发锁争用与全表扫描，导致超时。
触发器里 SELECT 为什么不受 max_execution_time 限制
max_execution_time 对触发器内任何语句都无效——它只约束独立执行的 SELECT，不作用于 INSERT/UPDATE/DELETE 中的子查询，更不覆盖触发器上下文。你设了 SET SESSION max_execution_time = 500，但触发器里一个 SELECT ... FROM big_log_table WHERE status = 'pending' 还是跑了 8 秒，这完全正常。
真正耗时的不是“查询本身”，而是它被嵌套在事务中同步执行：锁住主表的同时，又去扫描一张没索引的流水表，导致整个事务卡住。排查时别盯着这个参数，直接看 SHOW PROCESSLIST 中该连接的 Time 值是否持续增长，Info 列是否显示触发器名或其内部 SQL。
- 用
SELECT * FROM information_schema.TRIGGERS WHERE EVENT_OBJECT_TABLE = 'your_table'确认触发器存在且STATUS = 'ENABLED' - 检查触发器内所有
SELECT是否加了必要索引，尤其注意WHERE条件字段是否在索引最左前缀上 - 避免在触发器中做跨表关联扫描，宁可用应用层异步补全，也不要让
UPDATE users拖着orders和inventory一起锁
如何快速确认是触发器导致超时
别改代码，先验证是不是它干的。MySQL 提供了轻量级隔离手段：临时重命名目标表，绕过触发器执行路径。
例如原表叫 orders，执行：RENAME TABLE orders TO orders_off, orders_backup TO orders;（提前建好空表 orders_backup）
再跑一遍原来超时的 UPDATE，如果耗时从 3200ms 降到 18ms，基本锁定触发器为根因。
- 禁用方式因数据库而异：PostgreSQL 可
ALTER TABLE orders DISABLE TRIGGER ALL；SQL Server 用DISABLE TRIGGER trg_orders_audit ON orders - MySQL 不支持运行时禁用，
DROP TRIGGER是唯一办法，但必须在维护窗口操作，并提前用SHOW CREATE TRIGGER记录定义 - 对比前后
INNODB_TRX中的trx_state和trx_started，若禁用后事务持有时间骤降，说明触发器逻辑拖长了锁周期
触发器超时的三类高危操作
很多团队把触发器当“自动任务调度器”用，结果把单条 DML 变成多阶段阻塞操作。以下行为在触发器中必须禁止：
-
CALL其他存储过程——尤其含循环、事务或SELECT FOR UPDATE的，会继承父事务上下文，放大锁持有时间 -
INSERT INTO audit_log SELECT ... FROM huge_table——触发器内执行等同于主 SQL 多套一层全表扫描，索引失效时极易秒变慢查询 - 任何外部依赖：
SELECT * FROM remote_db.table、调用 UDF 执行系统命令、甚至通过httpclient发起 HTTP 请求——这些不光拖慢事务，还可能因超时导致连接池满（HikariPool-1 active=80 idle=0）
这些操作单独看可能没问题，但一旦放进触发器，就等于把它们绑在主事务的同一根绳上，一卡全卡。
调试触发器超时问题的实操路径
触发器没法单步断点，只能靠“日志 + 隔离 + 模拟”三步定位卡点。
第一步，在触发器开头加日志写入（注意：日志表不能是触发器正在操作的主表）：INSERT INTO debug_trigger_log (table_name, action, ts) VALUES ('orders', 'before_update', NOW());
第二步，把触发器主体逻辑复制出来，封装成带参数的存储过程，手动传参运行，观察哪一行开始变慢；
第三步，用 EXPLAIN ANALYZE（PostgreSQL）或 SET STATISTICS IO ON（SQL Server）分析触发器内每条语句的实际执行计划和 I/O 开销。
- 特别注意
NEW.col和OLD.col引用是否合法——字段不存在会报ERROR 1327，但错误可能被静默吞掉，需查 MySQL 错误日志（/var/log/mysql/error.log） - 检查
DEFINER用户权限是否足够，比如触发器要往sys_log.audit_log写数据，DEFINER就必须有INSERT ON sys_log.audit_log权限 - 避免在触发器中使用
NOW()、UUID()等非确定性函数，尤其在binlog_format = STATEMENT模式下，可能导致复制中断或逻辑跳过
最常被忽略的是：触发器没有独立事务边界，它和主语句共用同一个事务。这意味着哪怕只是往日志表插一行，也会延长主表行锁的持有时间——并发稍高，立刻堆积。
