MySQL触发器禁止直接访问其他表，必须用单值子查询嵌入校验逻辑；不支持SELECT INTO、游标、JOIN或跨库访问；跨表读取需压缩为至多一行一列的子查询，配合IF、EXISTS或赋值语句使用。
不能直接“访问”，只能用单值子查询嵌入校验逻辑。MySQL触发器不支持在触发器体内执行独立的 SELECT ... INTO、游标遍历或跨表 JOIN，更不允许跨库访问。所有跨表读取必须压缩成一个返回至多一行一列的子查询，并塞进 IF、EXISTS 或赋值语句中。
为什么不能用 SELECT INTO 或 DECLARE 变量查其他表
常见错误是想先查再判断：
DECLARE user_status VARCHAR(20); SELECT status INTO user_status FROM users WHERE id = NEW.user_id; IF user_status != 'active' THEN ...
这看似合理，但实际有三个硬伤：
-
SELECT ... INTO在触发器里虽语法允许，但一旦子查询无结果，user_status会是NULL，后续!= 'active'判定恒为UNKNOWN，校验失效 - 若
users.id没索引，或NEW.user_id为非法值，查询可能变慢，拖累主INSERT - 多行返回时直接报错
Subquery returns more than 1 row，而SELECT INTO不自动加LIMIT 1
正确写法：用 EXISTS 或标量子查询替代两步操作
把判断逻辑压进子查询，靠数据库引擎自己裁剪：
IF NOT EXISTS (SELECT 1 FROM users WHERE id = NEW.user_id AND status = 'active') THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'User not found or inactive'; END IF;
或者用标量赋值做字段联动：
SET NEW.order_status = ( SELECT CASE WHEN u.is_vip = 1 THEN 'vip_priority' ELSE 'normal' END FROM users u WHERE u.id = NEW.user_id LIMIT 1 );
-
EXISTS对NULL安全：查不到就返回FALSE，不会因NULL导致逻辑跳过 - 标量子查询必须加
LIMIT 1，否则多行必报错；业务上应确保关联字段有唯一约束或索引 - 别在子查询里
SELECT *或JOIN多张表——触发器不支持，且锁风险陡增
BEFORE 触发器里查不到自增 ID，别依赖 NEW.id 做跨表关联
这是高频翻车点：NEW.id 在 BEFORE INSERT 中永远为空（哪怕字段是 AUTO_INCREMENT），因为 ID 还没生成。
- 想基于主键查其他表？只能改用业务唯一键，比如
NEW.order_no、NEW.external_id - 非要用 ID 做后续校验（如写日志、更新计数器）？必须换到
AFTER INSERT触发器里 - 千万别在
BEFORE里调LAST_INSERT_ID()——它返回的是上一条语句的 ID，不可靠
容易被忽略的锁与性能陷阱
触发器内查其他表不是“只读”那么简单：
- 即使只是
SELECT status FROM users WHERE id = ?，在默认隔离级别下也会加READ LOCK，若users表该行正被其他事务UPDATE，这里就会等锁 - 高并发写入时，多个触发器同时查同一张状态表（如
users），极易引发锁等待甚至死锁 - 真正稳定的方案是：把关键状态冗余到当前表（如加
user_status字段），或查带覆盖索引的缓存视图，而非实时 JOIN
