触发器中select…into可用，但查阶梯规则时必须加正确where条件；常见错误是遗漏条件或范围判断错误，导致查出多行或空值而报错。
触发器里不能直接用 SELECT ... INTO 变量来查阶梯规则
很多刚写触发器的人会想：先查出当前用户的等级、历史累计消费，再查对应阶梯折扣表，最后算折扣。但 MySQL 的 BEFORE UPDATE 触发器中，SELECT ... INTO 本身是允许的，问题出在「查阶梯表时没加 WHERE 条件或范围判断错」——比如用 WHERE amount 查到多条匹配记录，MySQL 会报 <code>Subquery returns more than 1 row 错误。
正确做法是用 ORDER BY threshold DESC LIMIT 1 拿最高一档匹配项：
SELECT discount_rate INTO v_discount FROM billing_tiers WHERE tier_level = v_user_level AND threshold <p>注意：<code>threshold</code> 是阶梯起点（如 1000 元档表示「满 1000 才享该档折扣」），必须降序取第一个，否则可能拿到最低档。</p> <h3>UPDATE 触发器中修改 NEW 字段要小心事务可见性</h3> <p>在 <code>BEFORE UPDATE</code> 里给 <code>NEW.discount_amount</code> 赋值，看起来简单，但容易忽略两个现实约束：</p>
- 如果原表没
discount_amount字段，触发器赋值无效（MySQL 不会自动新增列） - 若业务逻辑还依赖更新后的
discount_amount去算税费或积分，而这些计算在应用层做，那触发器改了NEW也没用——应用层读的还是旧值或没读这个字段 - 多个触发器叠加时，后创建的触发器会覆盖前一个对同一
NEW字段的修改
建议：只在字段真实存在于表结构中、且下游逻辑明确读取该字段的前提下，才在触发器里直接赋值；否则统一返回计算结果供应用层处理。
阶梯计费必须考虑「累计消费」和「当次消费」分离
常见错误是把本次更新的 consumed_amount 当成累计值去查阶梯，导致用户第一次消费 500 元就按「500 元档」打折，第二次再消费 600 元，累计 1100，却仍按「600 元档」算——因为触发器只看到本次值。
真正可用的方案是：
- 表里必须有
total_consumed累计字段，并在每次更新时原子递增（如total_consumed = total_consumed + NEW.amount_delta） - 触发器基于
NEW.total_consumed查阶梯，而不是NEW.amount_delta - 如果累计值不在同一张表，需用
JOIN或子查询从用户主表拉取，但要注意触发器中不允许对本表做 DML，所以只能SELECT，不能UPDATE users SET total = ...
换句话说：触发器不是万能计算器，它只适合「基于已有数据做确定性推导」，不负责跨行聚合或状态更新。
MySQL 8.0+ 支持窗口函数，但触发器里不能用
有人想用 SUM() OVER (PARTITION BY user_id ORDER BY created_at) 动态算累计消费，这在普通查询里很优雅，但在触发器里直接写会报 This function cannot be used in a trigger。MySQL 明确禁止在触发器中使用窗口函数、CTE、临时表等复杂结构。
替代方案只有两个：
- 提前在应用层或定时任务里维护好
users.total_consumed字段 - 在触发器中用关联子查询模拟累加（性能差，仅适用于低频更新场景）：
(SELECT SUM(amount) FROM orders o2 WHERE o2.user_id = NEW.user_id AND o2.id
别试图在触发器里“重造轮子”——它天生不是为复杂计算设计的。真要动态阶梯，宁可把逻辑移到应用层或用存储过程封装，也别硬塞进触发器。
最易被忽略的一点：触发器不走索引优化路径，哪怕你给 billing_tiers(tier_level, threshold) 加了联合索引，在触发器内执行的 SELECT 也可能被优化器忽略，务必用 EXPLAIN 验证单条触发器语句的执行计划。
