触发器读不到最新提交数据是因为共享父事务的Read View且复用MVCC快照；必须用SELECT ... FOR UPDATE等当前读强制获取已提交最新值，否则会因快照隔离导致余额校验失效或幻读。
触发器里读不到最新提交的数据，是因为 Read View 复用
MySQL 触发器运行在父事务上下文中，SELECT 语句默认走快照读（MVCC），不会看到其他事务刚 COMMIT 的修改。比如：事务 A 插入一行触发器执行 SELECT，此时事务 B 刚更新了关联表并提交，但触发器仍读到旧值——这不是 bug，是 REPEATABLE READ 隔离级别的正常行为。
关键点在于：触发器内没有独立事务生命周期，它共享父事务的 Read View，且该视图在父事务第一条语句执行时就已固定。
- 避免在触发器中依赖外部表的“实时状态”，尤其是那些可能被其他事务高频更新的表
- 若必须读取最新数据，改用
SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE强制当前读 - 注意：加锁会阻塞其他事务，可能引发死锁或性能下降，尤其在高并发写场景
用 SELECT ... FOR UPDATE 强制读取已提交的最新行
当触发器需要确保读到其他事务已提交的变更（比如校验余额、检查唯一性约束），必须显式使用当前读。仅靠提高隔离级别没用，因为触发器无法开启新事务来生成新 Read View。
示例：订单插入触发器需检查用户账户余额是否充足
DELIMITER $$
CREATE TRIGGER check_balance_before_order
BEFORE INSERT ON orders
FOR EACH ROW
BEGIN
DECLARE user_balance DECIMAL(10,2);
-- ❌ 错误：快照读，可能读到过期余额
-- SELECT balance INTO user_balance FROM accounts WHERE user_id = NEW.user_id;
<pre class="brush:php;toolbar:false;">-- ✅ 正确：当前读 + 行锁，确保读到最新已提交值
SELECT balance INTO user_balance
FROM accounts
WHERE user_id = NEW.user_id
FOR UPDATE;
IF user_balance <p>END$$
DELIMITER ;</p>
-
FOR UPDATE在匹配行上加临键锁（Next-Key Lock），既防止幻读又保证读到最新提交值 - 该语句会阻塞其他事务对同一行的
UPDATE/DELETE，但不阻塞普通SELECT - 如果查询条件无索引，可能升级为表锁，务必确认
user_id有索引
触发器中幻读比脏读更隐蔽，范围查询必须加锁
当触发器内执行类似 SELECT COUNT(*) WHERE status = 'pending' 这类范围查询时，即使其他事务只插入新记录（未修改已有行），也会出现幻读：两次查询结果行数不同。这是因为 MVCC 快照不包含新插入的已提交行。
解决方式不是换隔离级别（REPEATABLE READ 下快照读本身就不防幻读），而是锁定查询范围：
- 用
SELECT ... FOR UPDATE替代纯SELECT，InnoDB 会对满足条件的记录及间隙加 Next-Key Lock - 若业务允许放宽一致性，可改用
READ COMMITTED隔离级别——此时每个语句都会新建Read View，快照读也能看到其他事务刚提交的新增行（但仍不防不可重复读） - 极端情况：把范围校验逻辑移出触发器，放到应用层用显式事务控制，避免触发器内复杂锁竞争
真正容易被忽略的是触发器与主事务的锁持有时间
触发器中加的锁（如 FOR UPDATE）会一直持有着，直到整个主事务结束（COMMIT 或 ROLLBACK）。这意味着：一个慢触发器可能让一行锁住几秒甚至更久，而你只盯着触发器本身执行时间，却没意识到它拖住了整个事务的锁释放节奏。
这种延迟释放常导致连锁阻塞，尤其在批量导入、后台任务等场景下极易复现。
- 检查触发器是否真的需要锁整张表或大范围数据，优先缩小
WHERE条件的索引覆盖 - 避免在触发器里调用存储过程或远程服务，它们可能延长事务时间，间接拉长锁持有窗口
- 监控
INFORMATION_SCHEMA.INNODB_TRX和INNODB_LOCK_WAITS，重点看TRX_MYSQL_THREAD_ID对应的触发器 SQL 是否长期处于LOCK WAIT
