MySQL 5.7触发器内存不释放导致OOM，主因是sp_head实例长期驻留main_mem_root且被多分区重复加载；应先用Performance Schema定位，再通过减少副本数（调table_open_cache_instances=1）、精简触发器、显式清空变量等手段治理。
触发器太长会直接撑爆 memory/sql/sp_head::main_mem_root
MySQL 5.7 不会在触发器执行完就释放其内存，而是把整个 sp_head 实例长期留在 memory/sql/sp_head::main_mem_root 里。触发器代码越长（尤其是含大 SELECT ... INTO @var、多层嵌套 IF、拼接超长字符串），单个实例占用就越大；而表被频繁访问时，这个实例还会被反复加载进多个 table_open_cache_instances 分区——默认 16 个，内存直接翻 16 倍。
先确认是不是触发器在吃内存，别瞎改
别一上来就重写逻辑，先用 Performance Schema 锁定问题源：
- 确保已开启内存监控：
performance_schema_instrument = 'memory/% = COUNTED'（需重启生效） - 查当前占用：
SELECT EVENT_NAME, CURRENT_NUMBER_OF_BYTES_USED FROM performance_schema.memory_summary_global_by_event_name WHERE EVENT_NAME = 'memory/sql/sp_head::main_mem_root'; - 手动对目标表做一次
INSERT或UPDATE，再查一次该值，差值就是这次触发器实际吃掉的内存 - 定位具体触发器：
SELECT TRIGGER_NAME, ACTION_TIMING, EVENT_MANIPULATION FROM information_schema.TRIGGERS WHERE EVENT_OBJECT_TABLE = 'your_table';
不重写业务逻辑，也能压住内存增长
核心是减少“触发器副本数”和“单个副本体积”：
- 把
table_open_cache_instances从默认 16 改成 1：加配置table_open_cache_instances = 1，重启 mysqld。这是最立竿见影的手段，尤其当表有几十个触发器时 - 删掉非必要触发器：哪怕只留一个，只要它包含
SELECT ... INTO @big_var或循环拼接字符串，@big_var的内容也堆在main_mem_root里不释放 - 避免在触发器里做复杂计算或跨表查询：这些操作本身不报错，但每行都拷贝字段值进内存，数据量一大就崩
- 检查
max_connections是否过高：每个连接打开表都可能触发加载，连接数 × 触发器副本数 × 单副本大小 = 实际内存压力
真要改触发器代码，重点不是缩行，而是断链
缩短代码长度没用，关键得切断内存累积路径：
- 把大
SELECT ... INTO @var拆成小批次SELECT ... LIMIT 100+ 循环处理，每次只让少量数据进内存 - 所有
DECLARE的变量，尤其是字符串拼接类，必须在触发器末尾显式赋空值，比如SET @tmp_str = '';—— 这不会释放内存，但能防止下次调用时叠加残留 - 绝对不要在触发器里开游标：MySQL 不支持在触发器中
CLOSE游标，一旦声明就永久挂载在main_mem_root上 - 如果逻辑实在绕不开大结果集，考虑用外部应用层替代：比如把触发器改成发 MQ 消息，由独立服务消费后处理
真正麻烦的不是某段 SQL 写得长，而是 MySQL 把整个触发器上下文当“常驻对象”管理。哪怕你只改一行，只要没动 table_open_cache_instances 或清理掉冗余触发器，内存照样涨。
