可以调用，但必须满足四个硬性条件：禁止事务控制、禁止修改触发表、禁止跨库或非事务表访问、参数须严格匹配且仅限字面量/NEW/OLD字段；否则报错或静默失效。
可以调用，但必须满足四个硬性条件，缺一不可；否则不是报错就是静默失效。
CALL 语句在触发器里是否合法
合法，MySQL 允许在触发器中使用 CALL 调用存储过程，但仅限于符合上下文限制的过程。触发器本身运行在语句级事务中，所有被调用的逻辑都共享这个事务边界。
- 不能出现
START TRANSACTION、COMMIT、ROLLBACK—— 否则直接报ERROR 1422 (HY000) - 存储过程定义的 SQL 数据访问特性必须是
READS SQL DATA或NO SQL，不能是MODIFIES SQL DATA且内部又含事务控制 - 过程内不能对当前正在被触发的表执行 INSERT/UPDATE/DELETE（即“mutating table”问题，MySQL 不报错但可能死锁或数据异常）
- 过程不能访问其他数据库中的表（尤其当跨库涉及 MyISAM 表或锁不一致时）
参数传递必须严格匹配
触发器能传给存储过程的参数非常受限：只能是字面量、NEW/OLD 字段、或简单表达式（如 CONCAT(NEW.email, '_arch')），不能是子查询、函数嵌套过深的结构，也不能是未声明的变量。
- IN 参数：可直接传
NEW.id、'default'、UNIX_TIMESTAMP() - OUT / INOUT 参数：必须传用户变量，例如
@log_id，不能传NEW.log_id（字段不可写） - 类型不匹配时不会自动转换，可能触发
ERROR 1366（字符集/截断）或静默丢精度 - 参数个数、顺序、类型必须与
CREATE PROCEDURE定义完全一致
为什么 CALL 看似成功却没效果
这不是语法问题，而是执行失败被事务吞掉了——触发器调用的存储过程如果内部出错（比如插入违反唯一约束、目标表不存在、权限不足），整个外部语句会回滚，但你只看到主 SQL 的错误，过程本身的错误日志默认不暴露。
- 建议在存储过程中加
DECLARE EXIT HANDLER FOR SQLEXCEPTION捕获并写入调试日志表 - 避免在触发器中多次
CALL同一过程，I/O 或计算密集型操作会显著拖慢主 DML 性能 - 不要依赖过程返回值做判断逻辑——触发器无法接收
RETURN值，只能靠用户变量或副作用（如写日志表）间接观察 - 测试时务必用真实 DML 触发（如
INSERT INTO ...），而不是单独CALL过程，否则绕过了触发器上下文限制
最易被忽略的一点：即使语法全对、参数全准，只要被调用的存储过程定义里漏写了 READS SQL DATA（或用了默认的空特性），MySQL 仍可能按最严策略拒绝执行——它会隐式推断为 MODIFIES SQL DATA 并卡在事务检查上。
