需通过日志打点定位慢触发器，如在开头结尾插入now(6)或写入debug_log表测微秒级耗时；禁用autocommit时无法单独查事务id；避免触发器内查同表或大表，改用应用层预查或加索引；检查show warnings和@@warning_count防静默失败；注意其与复制延迟及row格式的耦合影响。
触发器执行慢，怎么定位是哪条语句拖垮的
MySQL 触发器本身不记录执行耗时，SHOW PROFILES 和 SHOW PROFILE 对触发器内部语句无效，你看到的只是外层 SQL 的耗时。真正卡在触发器里，得靠日志和时间戳打点。
实操建议：
- 在触发器开头和结尾插入
SELECT NOW(6)或写入临时表（如INSERT INTO debug_log VALUES (UUID(), NOW(6), 'before_update')），用微秒级时间差判断瓶颈位置 - 禁用
autocommit时，触发器会和主语句共用事务，INFORMATION_SCHEMA.INNODB_TRX查不到触发器单独的事务 ID，别指望靠它捞执行栈 - 避免在触发器里调用
SLEEP()或USER()这类函数做调试——它们可能被优化掉，或引发不可预期的锁等待
触发器里查表导致性能雪崩的典型场景
最常见的是在 BEFORE INSERT 里查同一张表，或在 AFTER UPDATE 里查关联大表，MySQL 会隐式加锁甚至触发全表扫描。
实操建议：
-
SELECT ... FROM same_table WHERE x = NEW.y在BEFORE触发器中直接报错：Can't update table 't' in stored function/trigger because it is already used by statement which invoked this stored function/trigger - 改用
JOIN或应用层预查：把查表逻辑提到主 SQL 外，用变量传入触发器，比如SET @ref_value := (SELECT val FROM ref WHERE id = ?)，再在触发器里用@ref_value - 如果必须查，确保被查字段有索引，且避免
SELECT COUNT(*)、SELECT MAX()这类聚合——它们在高并发下极易成为热点
监控触发器是否被跳过或静默失败
触发器出错时，MySQL 默认中断整个语句并回滚，但有些错误（比如对不存在列赋值、INTO 变量类型不匹配）只报 warning，不会阻断执行，数据就悄悄错了。
实操建议：
- 检查
SHOW WARNINGS输出，重点看Level: Warning+Code: 1329（No data to FETCH）或Code: 1265（Data truncated）这类静默型提示 - 在触发器开头加
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION，配合INSERT INTO error_log记录异常，但注意 handler 不捕获 warning - 用
SELECT @@warning_count判断是否有未处理 warning；在测试环境开启sql_mode = 'STRICT_TRANS_TABLES,STRICT_ALL_TABLES'，让 warning 升级为 error
触发器和复制延迟之间的隐藏关联
主库上一个慢触发器，会导致 binlog 写入延迟，从库 relay log 回放卡在那条语句，Seconds_Behind_Master 突然飙升，但 SHOW PROCESSLIST 里看不到明显阻塞源。
实操建议：
- 检查
SHOW SLAVE STATUS\G中的Exec_Master_Log_Pos是否长期停滞，再比对主库mysql-bin.000001对应位置的事件内容（用mysqlbinlog --base64-output=DECODE-ROWS -v） - 如果触发器含非确定性函数（
NOW()、RAND()、UUID()），在 STATEMENT 格式复制下可能造成主从不一致，强制设为ROW格式，并确认binlog_row_image = FULL - 上线前用
pt-query-digest分析慢日志，过滤出含TRIGGER字样的行——它不会直接标出触发器名，但会显示原始 DML 语句及耗时
触发器不是黑盒，它的性能问题几乎都藏在“你以为它自动运行，其实它全程同步阻塞”这个事实里。最容易被忽略的，是它和事务边界、锁粒度、复制格式三者的耦合关系——改一行数据，可能牵动整个表的 binlog 位点推进。
