触发器里能用 SELECT … INTO 变量查用户状态，但必须用 DECLARE 声明局部变量、确保查询返回恰好一行，且不可用普通 SELECT 直接赋值，否则报 ERROR 1415；正确做法是 SELECT ... INTO v_status FROM users WHERE id = NEW.user_id。
触发器里不能用 SELECT … INTO 变量来查用户状态？
MySQL 触发器中禁止在 BEFORE INSERT 或 BEFORE UPDATE 里执行普通 SELECT 赋值（比如 SELECT balance INTO @bal FROM users WHERE id = NEW.user_id），会报错 ERROR 1415 (0A000): Not allowed to return a result set from a trigger。这不是语法写错了，是 MySQL 的硬性限制——触发器不允许返回结果集。
正确做法是用 SELECT ... INTO 配合变量声明，且必须确保查询只返回一行：
DECLARE v_used_count INT DEFAULT 0; DECLARE v_quota_left INT DEFAULT 0; <p>SELECT COUNT(*) INTO v_used_count FROM coupon_usage WHERE user_id = NEW.user_id AND coupon_id = NEW.coupon_id;</p><p>SELECT quota - used_count INTO v_quota_left FROM coupons WHERE id = NEW.coupon_id;
注意两点：一是所有变量必须 DECLARE 在触发器开头；二是 SELECT ... INTO 必须严格单行，否则触发器运行时会报 ERROR 1329 (02000): No data to fetch 或 Subquery returns more than 1 row。
如何在 BEFORE INSERT 中阻止非法领取并返回明确错误？
MySQL 触发器本身不支持 RAISE ERROR，但可以用 SIGNAL 主动抛出异常，让上层事务中断并看到具体原因：
IF v_used_count > 0 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Coupon already claimed by this user'; END IF; <p>IF v_quota_left <= 0 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Coupon out of stock'; END IF;</p><p>IF NOT EXISTS (SELECT 1 FROM users WHERE id = NEW.user_id AND status = 'active') THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'User is not active'; END IF;
关键点：
-
SIGNAL SQLSTATE '45000'是通用自定义错误码，应用层能捕获并解析MESSAGE_TEXT - 不要依赖
INSERT后再删——那样已写 binlog、可能被从库同步，且并发下有竞态 - 校验顺序建议按“高频失败项前置”：比如先查是否已领（快），再查库存（需 JOIN），最后查用户状态（可能涉及远程服务缓存）
优惠券叠加规则和时间校验为什么不能只靠触发器？
触发器适合做原子级、单表强约束（如“每人限领1张”），但复杂业务规则往往跨维度：
- “同一用户 24 小时内最多领 3 张满减券” → 需查
coupon_usage表最近记录，但触发器无法高效走WHERE created_at > NOW() - INTERVAL 1 DAY索引（尤其高并发时） - “新用户专享券仅限注册 7 天内领取” → 要关联
users.registered_at，但触发器里 JOIN 多表性能敏感，且registered_at可能为空或被更新 - “A 券和 B 券互斥” → 需提前锁定相关记录，触发器无事务外加锁能力，易出现幻读
实际方案通常是：触发器做基础拦截（重复领、库存、状态），复杂规则由应用层在事务开始前查库+加行锁（SELECT ... FOR UPDATE），再决定是否发 INSERT。
为什么上线前必须测试并发领取场景？
触发器逻辑在单线程下没问题，但真实环境多个请求同时 INSERT 同一优惠券 ID，会出现典型竞态：
- 两个事务几乎同时查到
v_quota_left = 1 - 都通过校验，都执行 INSERT
- 最终库存变成 -1
根本原因：触发器里的 SELECT ... INTO 不带锁，不是当前读。解决方法只有两种：
— 在应用层用 SELECT quota, used_count FROM coupons WHERE id = ? FOR UPDATE 先锁住券记录，再计算并更新；
— 或改用存储过程封装“查-判-更”为原子操作，但依然要配合 FOR UPDATE。
单纯靠触发器无法解决超领问题，这点很容易被忽略——尤其是压测时用单线程脚本没暴露出来，上线后突发超发。
