先说个结论：在SQL触发器里调用存储过程，性能表现往往不如直接写SQL，差距可不是一点半点——实测中，一个包含三层嵌套查询的存储过程，在500 QPS的写入压力下，能让触发器的平均延迟从0.8ms飙到12ms，十倍差距是真实存在的。
那么问题出在哪？
你猜怎么着？每次触发器触发存储过程，都相当于重新走一遍完整的调用链路：参数拷贝、权限校验、执行计划重解析……而触发器本身又在事务内部同步阻塞执行，等于整个写入流程都得等它。这还不是最要命的，更隐蔽的开销藏在这个调用机制里：
- 如果存储过程没有声明
DETERMINISTIC，MySQL就无法缓存它的执行计划，每次调用都要重新生成； - 参数类型不匹配——比如你传了一个
VARCHAR给期望INT的参数，隐式类型转换立刻生效，索引直接失效； - 存储过程内部如果还带着
SELECT或PERFORM（PostgreSQL场景），等于在触发器里又嵌套了一层查询，锁的范围随之扩大； - 还有一点：MySQL不支持对存储过程做语句级缓存，而触发器每行变更都会调用一次，批量插入场景下，开销是指数级放大的。
哪些场景最容易踩坑？
如果你的业务正好撞上下面这些情况，几乎必然引发性能雪崩：
- 触发器作用于高频写入表，比如日志、订单明细，而存储过程里还带着
JOIN或ORDER BY； - 存储过程的参数名不小心跟
NEW/OLD字段重名，导致值被意外覆盖，逻辑静默失效——这种bug查起来非常痛苦； - 用了
INOUT参数——MySQL在这类参数的大批量处理上表现极不稳定，容易丢数据； - 存储过程没有显式声明
READS SQL DATA，优化器可能误判为无副作用，跳过关键优化步骤。
不删存储过程，怎么让触发器快起来？
说实话，我不建议完全放弃存储过程，毕竟它的复用价值还是有的。但触发器调用这个环节，完全可以绕过瓶颈：
- 把简单逻辑直接展开写进触发器体——比如状态映射：
CASE WHEN status=1 THEN 'active'，这种活儿真没必要绕路调用存储过程； - 复杂逻辑改用异步方式：触发器只写入轻量消息表（比如
trigger_queue），后台任务轮询消费，这样写入链路上的压力直接降了一个量级； - MySQL 8.0+ 可以用
INSERT ... ON DUPLICATE KEY UPDATE替代“查再更”类逻辑，彻底避开存储过程调用； - 如果一定要复用某个存储过程，确保它是
DETERMINISTIC+READS SQL DATA，并且所有输入字段都建有索引。
最后想说一个最容易被忽视的点：触发器里哪怕只调一次存储过程，只要它内部查询了没有索引的字段，整个写入链路就会卡在那个点上——不是看代码行数，而是看实际执行计划里有没有 type: ALL。这才是真正的性能杀手。
