是，MySQL触发器中CALL存储过程会报ERROR 1422，但根本原因在于被调用的存储过程中含有COMMIT、ROLLBACK、START TRANSACTION等显式或隐式提交操作，违反了触发器必须依附父DML事务的原子性约束。
MySQL触发器里CALL存储过程会报ERROR 1422吗
会，但不是因为“不能调”，而是过程内部做了MySQL禁止的事。触发器本身允许CALL，但被调用的存储过程一旦含COMMIT、ROLLBACK、START TRANSACTION，或隐式提交（比如写MyISAM表），就会立刻触发ERROR 1422。
常见踩坑点：
-
DELIMITER $$ CREATE PROCEDURE log_audit() BEGIN INSERT INTO audit_log ...; COMMIT; END$$—— 这个COMMIT在触发器里直接非法 - 过程里查了非事务引擎表（如MyISAM），哪怕只是
SELECT，也可能导致隐式提交 - 过程定义为
MODIFIES SQL DATA却没加READS SQL DATA或NO SQL显式声明，MySQL 8.0+会更严格校验
SQL Server触发器调用存储过程要传参吗
必须传，且只能通过局部变量中转。SQL Server触发器没有NEW/OLD伪表，得从inserted或deleted临时表里SELECT出来再传。
典型写法：
CREATE TRIGGER trg_AfterInsertUser ON Users AFTER INSERT AS
BEGIN
DECLARE @UserName NVARCHAR(50), @UserEmail NVARCHAR(100);
SELECT @UserName = UserName, @UserEmail = UserEmail FROM inserted;
EXEC dbo.LogNewUser @UserName, @UserEmail;
END
注意：
- 不能直接
EXEC dbo.LogNewUser (SELECT UserName FROM inserted)——子查询不被允许 - 如果
inserted有多行（批量插入），上面写法只取一行，需改用游标或集合操作 -
EXEC不是CALL，SQL Server用EXEC或EXECUTE
触发器调用存储过程后数据没更新，是静默失败吗
极大概率是。MySQL触发器里CALL失败不会单独报错，而是让整个外部DML语句回滚，并抛出主语句的错误（比如INSERT失败），你可能根本没看到存储过程内部的ERROR 1062（重复键）或ERROR 1146（表不存在）。
排查建议：
- 先确认被调过程是否能在
mysql> CALL proc_name(...);下独立跑通 - 检查过程里所有
INSERT/UPDATE目标表是否都是InnoDB、且没被触发器自身监控 - 查MySQL错误日志：
grep -i "error 1[0-9]\{3\}" /var/log/mysql/error.log - 避免用
SELECT ... INTO赋值——没匹配行时变量变NULL，后续逻辑可能跳过
为什么BEFORE触发器里调用过程改NEW字段总失效
因为参数传递方式不对。MySQL触发器不能把NEW当对象传入过程，必须拆成标量，且输出要用用户变量中转。
正确姿势：
DELIMITER $$
CREATE PROCEDURE set_full_name(IN p_first VARCHAR(50), IN p_last VARCHAR(50), OUT p_full VARCHAR(101))
BEGIN
SET p_full = CONCAT(TRIM(p_first), ' ', TRIM(p_last));
END$$
CREATE TRIGGER user_bi BEFORE INSERT ON users FOR EACH ROW
BEGIN
CALL set_full_name(NEW.first_name, NEW.last_name, @tmp_full);
SET NEW.full_name = @tmp_full;
END$$
DELIMITER ;
关键点：
- 不能写
SET NEW.full_name = CALL set_full_name(...)——语法错误 - 必须用
@tmp_full这类用户变量接收OUT参数，不能用局部变量 -
NEW字段只读可写，但必须在BEGIN...END块内SET，不能跨语句延迟赋值
INSERT的目标表是否和触发器所在表隔离、OUT参数是否用了用户变量、以及错误是否被主语句吞掉。 
