触发器内开游标会导致每行变更都触发一次独立游标执行，引发N次全量查询、锁竞争加剧、WAL日志暴增及事务延迟；根本解法是用集合操作替代游标，而非优化游标本身。
触发器里开游标 = 每行都重新启动一次事务
触发器本就是行级同步执行的，一旦在 AFTER INSERT 或 BEFORE UPDATE 里声明并打开游标，数据库会为每一行变更都完整走一遍游标生命周期：分配内存、初始化结果集、逐行 FETCH、执行循环体、关闭释放。这不是“一次游标处理多行”，而是“N 行变更 → N 次游标创建 + N 次全量查询”。比如一条 INSERT INTO orders VALUES (1),(2),...,(10000)，有游标触发器就等于执行 10000 次独立的 SELECT ... FROM big_table WHERE user_id = ?。
- 每次游标打开都可能触发一次全表扫描（尤其没索引时），
EXPLAIN显示type: ALL就是典型信号 - 游标结果集默认缓存在内存或临时表（
Created_tmp_disk_tables突增可验证） - 事务持有时间被拉长，
innodb_row_lock_time_avg和Handler_wait_*指标会明显升高 - MySQL 不会在慢日志里记录游标内 SQL，但
performance_schema.events_statements_history_long能抓到带TRIGGER字样的事件
游标嵌套在触发器中会放大锁竞争和 WAL 压力
游标本身不加锁，但它执行的每条 SELECT 或 UPDATE 都会按需申请行锁、页锁甚至表锁；而触发器又强制这些操作串行化执行。更危险的是 WAL（Write-Ahead Logging）——原本一次批量写入只记 1 条 binlog，现在变成 N 条独立事务日志，主从延迟、磁盘 I/O、buffer pool 压力全跟着翻倍。
- 常见现象：
Innodb_os_log_written曲线在批量导入时异常凸起，远超数据量增长比例 - 若游标内有
UPDATE stats SET cnt = cnt + 1 WHERE type = NEW.type，而stats(type)无索引，就会锁住整个stats表的匹配范围 - PostgreSQL 中可通过
pg_stat_activity查backend_start与xact_start时间差，差值 >500ms 基本可判定是游标拖住了事务
替代方案不是“优化游标”，而是绕过它
给游标加索引、换 STATIC READ_ONLY、甚至用临时表预加载，都只是缓解表象。真正有效的路径是彻底去掉触发器里的游标逻辑，把“逐行响应”转成“集合响应”。
- 用
INSERT ... SELECT或UPDATE ... JOIN替代游标循环内的单行INSERT/UPDATE - 统计类需求改用语句级触发器（
FOR EACH STATEMENT）+ 过渡表（NEW TABLE），避免逐行调用 - 字段自动更新（如
updated_at）优先用生成列：updated_at DATETIME AS (NOW()) STORED（MySQL 8.0+） - 必须做复杂判断的场景，把逻辑提到应用层，用客户端做聚合、过滤、重试，数据库只负责原子读写
真实生产中最容易被忽略的一点：**触发器里的游标根本不会出现在主 SQL 的 EXPLAIN 结果里**。你看到的执行计划干净漂亮，但吞吐量已经断崖下跌——因为真正的瓶颈藏在看不见的地方。
