SQL触发器的原子性指的是触发器内的所有操作要么全部执行成功，要么全部不执行，不会出现部分操作生效的情况，当我们将业务逻辑包裹在触发器内部时，必须做好相关控制才能保障这一特性。
触发器原子性的核心原理
触发器的执行是依附于触发它的DML操作（INSERT、UPDATE、DELETE）所在的事务的，默认情况下，如果触发器内部抛出错误，整个触发操作以及对应的DML操作都会回滚，这就是基础的原子性保障。但如果触发器内部包含多个独立的操作，且没有做好异常处理，就可能出现部分逻辑执行成功的情况。
常见的原子性破坏场景
- 触发器内包含多个数据修改语句，前一条执行成功，后一条执行失败，没有做统一的回滚控制
- 触发器内调用了存储过程，存储过程内部有独立的错误处理，导致部分操作提交
- 触发器内涉及跨表操作，其中某个表的约束校验失败，其他表的操作已经生效
将业务逻辑包裹到触发器内的实现方式
将业务逻辑放到触发器内时，需要把相关的所有操作都纳入同一个事务控制范围，同时做好异常捕获，确保任何一步出错都能回滚所有操作。
MySQL中的实现示例
MySQL的触发器本身不支持直接写事务控制语句，但是可以通过在触发器内抛出异常来触发所在事务的回滚，我们可以把业务逻辑的所有步骤按顺序写在触发器里，任何一步失败就抛出自定义异常。
-- 创建测试表
CREATE TABLE order_info (
order_id INT PRIMARY KEY,
product_id INT,
quantity INT,
total_price DECIMAL(10,2)
);
CREATE TABLE product_stock (
product_id INT PRIMARY KEY,
stock_num INT
);
-- 创建触发器，下单时扣减库存，将业务逻辑包裹在触发器内
DELIMITER //
CREATE TRIGGER update_stock_after_order_insert
BEFORE INSERT ON order_info
FOR EACH ROW
BEGIN
DECLARE current_stock INT;
-- 查询当前商品库存
SELECT stock_num INTO current_stock FROM product_stock WHERE product_id = NEW.product_id;
-- 库存不足则抛出异常
IF current_stock < NEW.quantity THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '商品库存不足，无法下单';
END IF;
-- 扣减库存
UPDATE product_stock SET stock_num = stock_num - NEW.quantity WHERE product_id = NEW.product_id;
-- 如果上面的更新失败，下面的设置总价逻辑不会执行，因为上面的异常会触发回滚
SET NEW.total_price = NEW.quantity * (SELECT unit_price FROM product_price WHERE product_id = NEW.product_id);
END //
DELIMITER ;
PostgreSQL中的实现示例
PostgreSQL的触发器函数可以更灵活地处理异常，我们可以使用BEGIN...EXCEPTION块来捕获错误，手动控制回滚逻辑。
-- 创建测试表
CREATE TABLE order_info (
order_id INT PRIMARY KEY,
product_id INT,
quantity INT,
total_price DECIMAL(10,2)
);
CREATE TABLE product_stock (
product_id INT PRIMARY KEY,
stock_num INT
);
-- 创建触发器函数
CREATE OR REPLACE FUNCTION update_stock_after_order_insert()
RETURNS TRIGGER AS $$
DECLARE
current_stock INT;
unit_price DECIMAL(10,2);
BEGIN
-- 查询当前库存
SELECT stock_num INTO current_stock FROM product_stock WHERE product_id = NEW.product_id;
-- 库存不足抛出异常
IF current_stock < NEW.quantity THEN
RAISE EXCEPTION '商品库存不足，无法下单';
END IF;
-- 扣减库存
UPDATE product_stock SET stock_num = stock_num - NEW.quantity WHERE product_id = NEW.product_id;
-- 查询单价计算总价
SELECT price INTO unit_price FROM product_price WHERE product_id = NEW.product_id;
NEW.total_price = NEW.quantity * unit_price;
RETURN NEW;
EXCEPTION WHEN OTHERS THEN
-- 捕获所有异常，回滚操作
RAISE;
END;
$$ LANGUAGE plpgsql;
-- 创建触发器
CREATE TRIGGER update_stock_trigger
BEFORE INSERT ON order_info
FOR EACH ROW
EXECUTE FUNCTION update_stock_after_order_insert();
保障触发器原子性的关键技巧
1. 避免触发器内的独立提交操作
不要在触发器内部使用COMMIT、COMMIT WORK这类提交语句，因为触发器的操作属于外层DML事务的一部分，手动提交会破坏整体的原子性，导致前面的操作无法回滚。
2. 统一异常处理逻辑
如果触发器内调用了其他的存储过程或者函数，要确保这些子程序没有独立的异常处理和提交逻辑，最好让所有子程序的错误都向上抛出，由触发器的外层事务统一处理回滚。
3. 合理拆分过长的业务逻辑
如果业务逻辑非常复杂，包含十几甚至几十个操作步骤，不建议全部塞到触发器内，因为触发器的调试难度较高，过长逻辑也不利于维护。可以将核心的、必须和DML操作强绑定的一致性逻辑放在触发器内，其他非核心逻辑放到业务层处理。
4. 测试边界场景
开发完成后要测试各种边界场景，比如库存刚好等于下单数量、库存不足、关联表不存在对应数据、字段违反约束等情况，确认所有场景下要么全部操作成功，要么全部回滚，没有残留的不一致数据。
注意事项
不同数据库对触发器的原子性支持有差异，比如SQL Server的触发器内可以使用ROLLBACK语句直接回滚整个事务，而MySQL只能在触发器内抛出异常来触发回滚。在实际开发前要先确认所用数据库的触发器特性，避免写出不符合预期的代码。另外触发器是隐式执行的，过多的复杂业务逻辑放在触发器内会降低代码的可读性，团队开发时要做好相关文档说明，避免后续维护人员不清楚数据变更的前置逻辑。