MySQL触发器中不能使用SELECT ... FOR UPDATE，应改用带WHERE条件的UPDATE语句重算has_active_items字段，并确保items(category_id, status)有联合索引，同时需定义AFTER INSERT/UPDATE/DELETE三个触发器统一处理，避免逻辑遗漏与性能瓶颈。
触发器里不能直接用 SELECT ... FOR UPDATE 锁分类表
商品上下架常需同步更新分类的 has_active_items 字段（比如“该分类下是否有在售商品”），但很多人一上来就在触发器里写 SELECT ... FOR UPDATE 去锁分类表，结果报错：Can't use SELECT ... FOR UPDATE in stored function or trigger。MySQL 触发器不支持显式加锁语句，这是硬限制。
正确做法是改用 UPDATE 直接修改，并靠 WHERE 条件确保幂等性：
UPDATE categories
SET has_active_items = (
SELECT COUNT(*) > 0
FROM items
WHERE items.category_id = categories.id
AND items.status = 'on'
)
WHERE id = NEW.category_id;
- 避免子查询返回 NULL：用
COUNT(*) > 0而不是EXISTS，MySQL 在触发器中对EXISTS子查询支持不稳定 - 必须带
WHERE id = NEW.category_id，否则会全表扫描更新，性能崩盘 - 如果分类表有上万行，这个 UPDATE 会成为瓶颈——得确认
items(category_id, status)有联合索引
AFTER UPDATE 触发器比 BEFORE 更安全
想让上下架变更生效后才去联动分类，必须用 AFTER UPDATE。用 BEFORE UPDATE 时，NEW.status 还没真正写入，且若触发器里再改 NEW.status，逻辑容易失控。
典型错误是把状态判断写成 IF OLD.status != 'on' AND NEW.status = 'on'，漏掉从 off 切到 draft 等中间状态。更稳妥的是只关注终态：
- 只要
NEW.status = 'on'，就置为“有在售” - 只要
NEW.status != 'on'，就重算该分类是否还有其他on商品（不能简单设为 false） - 所以推荐统一走上面那个带子查询的
UPDATE，不分支判断
INSERT/DELETE 也得覆盖，否则数据会错乱
只监听 UPDATE 不够。新上架商品（INSERT）或彻底下架删库（DELETE）同样影响分类状态。这三个触发器必须共存：
-
AFTER INSERT：当NEW.status = 'on'，更新对应分类的has_active_items -
AFTER DELETE：用OLD.category_id重算该分类是否还有其他on商品 -
AFTER UPDATE：如前所述，统一按新状态重算
漏掉任意一个，比如上线新商品但没触发器，分类的 has_active_items 就会是 false，前端显示“该分类暂无商品”，实际却有。
触发器里别调用存储过程或外部函数
有人想把重算逻辑抽成存储过程，然后在触发器里 CALL update_category_flag(...)。这看似整洁，但 MySQL 触发器中调用含事务控制（START TRANSACTION）、游标或临时表的存储过程，极大概率报错：Not allowed to return a result set from a function or trigger 或死锁。
坚持把逻辑写在触发器体内，哪怕重复几行 UPDATE。如果真要复用，只能用纯 SQL 函数（DETERMINISTIC + 无副作用），但这类函数无法执行 UPDATE，意义不大。
真正难处理的是并发——两个商品同时上架同一分类，可能都查到“当前无 on 商品”，都设成 true，没问题；但若一个上架、一个下架，靠子查询重算能自然收敛。最怕的是没加索引导致 UPDATE 慢，把整个分类表锁住几秒。
