SQL触发器如何应对并发更新引发的脏读

SQL触发器无法防止脏读，因其非隔离机制；脏读由事务隔离级别决定，需通过提升隔离级别（如READ COMMITTED）或使用SELECT ... FOR UPDATE加锁来解决。

SQL触发器本身不解决脏读

触发器不是隔离机制，它无法阻止脏读发生。脏读是事务隔离级别决定的，而触发器只是在 INSERT、UPDATE 或 DELETE 执行前后自动运行的一段逻辑。哪怕你在 UPDATE 上定义了 FOR EACH ROW 触发器，只要事务没提交，其他事务仍可能以 READ UNCOMMITTED 隔离级别读到未提交的中间状态——触发器对此完全无干预能力。

为什么在触发器里加 SELECT 很危险

常见错误是在触发器中写类似 SELECT balance FROM accounts WHERE id = NEW.id 的语句，试图做余额校验或日志记录。问题在于：

• 如果当前事务还没提交，这条 SELECT 读到的是本事务的“最新值”，但其他事务此时若用 READ UNCOMMITTED 也能看到它——这不是触发器造成的，而是隔离级别放行的
• 更糟的是，如果触发器里又去更新另一张表（比如记操作日志），而那张表被其他并发事务同时修改，就可能引发死锁或违反约束
• MySQL 的 BEFORE UPDATE 触发器中不能对同表执行 SELECT ... FOR UPDATE，会报错 ERROR 1442

真正该控制的地方是事务隔离级别和应用层调用方式

要避免脏读，必须从源头收紧读行为，而不是指望触发器兜底：

• 把应用中所有可能读取关键业务数据（如账户余额、库存）的查询，显式设置为 READ COMMITTED 或更高——MySQL 默认就是 READ COMMITTED，但 PostgreSQL 默认是 REPEATABLE READ，需确认
• 不要在连接初始化时全局设 SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED，这是自埋雷
• 如果业务逻辑强依赖“读-改-写”原子性（比如扣款前查余额），应改用 SELECT ... FOR UPDATE 显式加行锁，而不是靠触发器里的普通 SELECT
• 触发器只适合做副作用小、无外部依赖的操作：比如自动生成 updated_at 字段、写入审计日志表（且该表不参与核心业务读写路径）

并发更新冲突时触发器反而可能放大问题

两个事务同时更新同一行，都触发了相同逻辑，容易导致：

• 重复插入日志（比如双份扣款记录）
• 误判业务状态（如触发器里检查“余额是否为0”，但两个事务几乎同时读到非零值，都继续执行，结果透支）
• 嵌套触发器调用加深锁等待，加剧超时风险

真正需要防并发写冲突的地方，是主业务 SQL 本身——用 UPDATE ... WHERE balance >= ? 带条件更新，或引入乐观锁字段（version），而不是把判断逻辑塞进触发器。