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），而不是把判断逻辑塞进触发器。
