触发器会自动加入当前事务吗
是的，MySQL 中的触发器默认自动加入调用它的 SQL 语句所处的事务中。也就是说，
INSERT、
UPDATE或
DELETE触发的触发器，其内部所有操作（比如对另一张表的
INSERT）和原语句共享同一个事务上下文。
这意味着：
如果触发器内执行失败（例如违反外键、唯一约束或显式SIGNAL），整个事务会回滚，包括原语句和触发器里的修改 触发器里不能执行
COMMIT、
ROLLBACK或任何隐式提交语句（如
CREATE TABLE），否则会报错
ERROR 1305 (42000): SAVEPOINT does not exist或更常见的
ERROR 1617 (HY000): Cannot execute statement in a READ ONLY transaction
AFTER触发器能看到原语句已写入但尚未提交的数据，
BEFORE触发器则可修改
NEW行值（仅限
INSERT/
UPDATE）
如何在触发器中安全地做数据校验与拦截
MySQL 不支持在触发器中直接
RETURN或跳过原操作，但可通过
SIGNAL抛出异常来中断事务。这是最常用且可靠的方式。
示例：禁止插入年龄小于 0 的用户
DELIMITER $$
CREATE TRIGGER check_age_before_insert
BEFORE INSERT ON users
FOR EACH ROW
BEGIN
IF NEW.age < 0 THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Age cannot be negative';
END IF;
END$$
DELIMITER ;注意点：
SIGNAL必须配合
SQLSTATE（5 位字符串，
'45000'是通用未定义错误） 不要用
SELECT ... INTO做条件判断后忽略操作——这无法阻止原语句执行 避免在触发器中调用存储函数或过程，若它们内部含非确定性操作（如访问临时表、调用
NOW()），可能引发复制不一致
触发器与主从复制的兼容性风险
在基于语句复制（SBR，默认旧模式）下，触发器行为可能在从库不一致。因为主库上触发器由原始语句“激发”，而从库重放的是原始语句本身，不会再次执行触发器（除非显式开启
binlog_format = ROW并设置
slave-parallel-type = LOGICAL_CLOCK等）。
实际影响：
主库触发器写了审计日志表，从库该表为空 → 数据不一致 主库触发器修正了NEW.timestamp，但从库没运行，字段值不同 MySQL 5.7+ 默认
binlog_format = STATEMENT时，
CREATE TRIGGER会被记录为
SET sql_log_bin = 0，即触发器定义不复制到从库
解决方案：
统一使用binlog_format = ROW，确保 DML 变更按行复制，触发器逻辑保留在主库，从库只同步最终数据状态 避免在触发器中依赖会话变量（如
@user_id）、临时表或用户自定义函数（UDF） 若必须用触发器做关键业务逻辑（如库存扣减），建议改用应用层事务 + 显式 SQL 控制，更可控
替代触发器的更可控方案：应用层事务封装
多数业务场景下，把校验、关联更新、日志记录等逻辑放在应用代码中，配合显式事务，比依赖触发器更清晰、易测、可调试。
例如 Python + PyMySQL 中实现“下单并扣库存”：
conn.begin()
try:
cursor.execute("UPDATE products SET stock = stock - %s WHERE id = %s AND stock >= %s", (qty, pid, qty))
if cursor.rowcount == 0:
raise ValueError("Insufficient stock")
cursor.execute("INSERT INTO orders (pid, qty) VALUES (%s, %s)", (pid, qty))
conn.commit()
except Exception:
conn.rollback()
raise优势明显：
错误分支明确，可记录详细上下文日志 能结合缓存（如 Redis 库存预占）提升并发性能 规避触发器嵌套、递归、复制延迟等 MySQL 内部机制带来的黑盒问题 便于单元测试，无需启动真实数据库实例触发器真正适合的，其实是极轻量、强一致性要求、且与业务逻辑解耦的场景，比如自动生成
created_at、强制更新
updated_at、或 DBA 级别的操作审计——其余情况，先想清楚是不是真需要它。
