mysql触发器中使用游标会显著降低性能，因每次触发需重新编译、内存暴涨、阻塞并行且易引发锁争用和全表扫描。
MySQL触发器里用游标，基本等于主动给每条INSERT/UPDATE加10ms以上延迟，且并发越高越卡死——这不是配置问题，是机制决定的。
为什么游标在触发器里比在存储过程中更危险
触发器执行环境受限，无法复用执行计划、不能提前预热缓存、事务上下文强绑定，导致游标开销被放大：
- 每次触发都重新编译游标定义，
CURSOR FOR SELECT语句无法走查询缓存 - 游标打开时会把整个
SELECT结果集加载进内存（尤其STATIC类型），而inserted或NEW表本身已占内存，叠加后极易触发tmp_table_size溢出，转成磁盘临时表 - 触发器中
FETCH操作必须等前一行处理完才能取下一行，彻底阻塞并行优化器——哪怕你只插100行，执行计划也永远是type: ALL+rows: 100，而不是一次INSERT ... SELECT的type: range+rows: 1 - 错误日志里出现
Waiting for table metadata lock，大概率是游标正持着user_profiles表锁，而另一会话想改users表结构
游标内部SQL没走索引的典型表现
不是游标本身慢，是它包裹的那条SELECT或UPDATE在裸奔：
-
EXPLAIN SELECT id FROM orders WHERE user_id = NEW.user_id返回type: ALL，说明orders(user_id)没索引 - 触发器里写
UPDATE stats SET count = count + 1 WHERE type = NEW.type，但stats(type)无索引 → 每次更新都全表扫，100行插入就扫100次 -
JOIN字段类型不一致，比如users.id是BIGINT，而logs.user_id是INT，导致索引失效，Extra字段出现Using join buffer - 用
UUID()或NOW()这类非确定性函数，高并发下争抢系统时钟资源，单次调用实测增加0.5ms固定开销
游标导致内存暴涨的三个信号
别等OOM才察觉，这些指标一涨就得立刻查：
-
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables'值突增 → 游标结果集撑爆tmp_table_size，落地磁盘临时表 -
SHOW ENGINE INNODB STATUS里ROW OPERATIONS部分显示fetch次数远高于insert次数 → 游标在反复回表 -
performance_schema.memory_summary_global_by_event_name中memory/sql/Query_cache或memory/sql/THD::main_mem_root占用飙升 → 游标状态对象吃掉大量线程私有内存 - 监控发现
innodb_buffer_pool_pages_dirty持续高位，但innodb_io_capacity没跑满 → 游标长时间持有页锁，脏页无法刷出
真要保留游标逻辑，必须加的硬约束
没有兜底限制的游标，就是生产环境定时炸弹：
- 开头加
IF (SELECT COUNT(*) FROM inserted) > 50 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Too many rows for cursor processing'; END IF; - 游标声明必须用
READ ONLY和NO SCROLL，禁用UPDATE WHERE CURRENT OF这类隐式锁 - 所有
FETCH后立刻检查@@FETCH_STATUS = 0，避免空循环消耗CPU - 绝对不用
DECLARE CONTINUE HANDLER FOR NOT FOUND来代替显式判断——它会掩盖真实错误，比如锁超时被当成“没数据”静默跳过
真正难处理的不是语法怎么写，而是当业务方坚持“必须逐条发消息”时，你怎么说服他把INSERT INTO outbox_queue SELECT id, 'notify' FROM inserted这行集合操作，从触发器里拎出去放到应用层队列里——否则再好的索引也扛不住游标在事务里一遍遍重放。
