触发器读不到新插入数据是MVCC快照机制导致的正常现象，因触发器共享父事务Read View；应优先使用NEW/INSERTED伪记录取值，或显式当前读（如SELECT ... FOR UPDATE），避免查表。
触发器里读不到新插入的数据，不是 bug，是 MySQL 和 SQL Server 在 REPEATABLE READ 或默认事务隔离级别下复用 MVCC 快照的必然结果。
触发器共享父事务的 Read View
INSERT 语句启动事务时，数据库就固定了当前事务的 Read View；触发器内所有 SELECT 默认走快照读，看到的是该视图生成时刻的数据状态。哪怕另一事务刚 COMMIT 了更新，触发器也看不到——它不感知“外部已提交”，只认自己事务开始那一刻的快照。
- 这个行为在 MySQL 的
REPEATABLE READ、SQL Server 的READ COMMITTED SNAPSHOT下都成立 -
AFTER INSERT触发器中查本表，仍可能读不到刚插的那行（尤其当查询条件没命中索引或用了非确定性函数） - 不要指望靠提高隔离级别解决：即使设成
SERIALIZABLE，触发器仍无法开启新事务来刷新 Read View
想读最新数据？必须用当前读加锁
唯一可靠的方式是显式使用当前读语句，强制跳过快照、访问最新已提交版本，并加锁防止并发篡改。
- MySQL 中写
SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE，确保读到最新值且阻塞其他写操作 - SQL Server 中用
SELECT ... WITH (UPDLOCK, HOLDLOCK)替代普通SELECT - 注意：无索引条件会升级为表级锁，务必确认
WHERE字段有有效索引 - 加锁会引入阻塞和死锁风险，高并发场景需压测验证
别绕弯子：直接从 NEW/INSERTED 表取值
如果只是想获取当前正在插入或更新的那行数据，根本不需要查表——触发器上下文里已经提供了现成结构。
- MySQL
BEFORE INSERT中，直接用NEW.column_name，它是内存中的值，无需查询 - SQL Server
AFTER INSERT中，查INSERTED表：SELECT id FROM INSERTED，多行时用集合操作，别尝试赋给单个变量 - Oracle 中对应
:new.column_name，但列名大小写敏感，建表若带双引号（如"ID"），这里也得写:new."ID" - 误用
@@IDENTITY查 ID 是常见错误：它返回的是触发器内部最后一条INSERT（比如日志表）的 ID，不是主表的
ORA-04091：不能读“正在变化的表”
Oracle 报这个错，是因为触发器试图在同一个事务里对被修改的表做 SELECT ——它不允许“一边改一边读”。这不是并发问题，是 Oracle 的硬性限制。
- 方案一：改用
:new和:old变量，避免查原表 - 方案二：加
PRAGMA AUTONOMOUS_TRANSACTION让触发器跑在独立事务里，但必须显式COMMIT，且无法回滚父事务的变更 - 方案三：把逻辑移到应用层或存储过程中，由调用方控制事务边界
- 切记：
AUTONOMOUS_TRANSACTION会切断事务一致性，审计类场景慎用
最常被忽略的一点：触发器不是万能胶水，它没法突破事务快照模型，也不能替代应用层的状态同步。依赖实时数据的校验逻辑，越早移到应用事务中处理，越可控。
