触发器是导致update后数据未变的隐蔽原因，尤其after update触发器可能覆盖新值；需用show triggers检查、验证赋值语句及类型匹配。
UPDATE后数据没变，先查有没有触发器在悄悄改值
触发器（TRIGGER）是导致“UPDATE看似成功、实际白干”的隐蔽元凶之一。它不报错、不阻塞、甚至不改变ROW_COUNT()，只在AFTER UPDATE里把刚写进去的值又覆盖掉——你看到的是最终结果，不是中间态。
常见表现：
执行UPDATE users SET status = 'active' WHERE id = 123后立刻SELECT，发现status还是'pending'；ROW_COUNT()返回1，说明行确实被更新了，但值又被重置了。
- 用
SHOW TRIGGERS LIKE 'users'查表上是否定义了AFTER UPDATE触发器（注意大小写，Linux下表名敏感） - 重点看触发器体里是否有
UPDATE ... SET xxx = ...或直接赋值NEW.status := 'pending'这类语句 - 临时禁用触发器验证：MySQL 8.0+ 支持
ALTER TABLE users DISABLE TRIGGER trigger_name；老版本只能DROP TRIGGER再重建（务必备份原逻辑） - 若触发器依赖其他表状态（比如检查订单表是否完成），记得连带查那些表当前数据是否满足触发条件
触发器里用NEW字段赋值时，别混淆类型和NULL行为
NEW不是变量，是行级上下文对象；对NEW.col赋值会直接覆盖本次UPDATE要写入的值。但它的行为受字段定义约束——比如对NOT NULL字段赋NULL，会触发隐式转换或报错（取决于sql_mode）；而对ENUM字段赋非法字符串，可能转成空字符串或默认值，表面看不出异常。
- 检查触发器中所有
NEW.xxx := ...语句右侧的值，是否与目标字段类型严格匹配 -
NEW.status = 'active'和NEW.status := 'active'语义完全不同：前者是判断，后者才是赋值（注意=vs:=） - 对
TEXT或JSON字段，在触发器里拼接字符串容易因隐式截断丢失内容，建议加CHAR_LENGTH(NEW.content) 类校验 - 触发器内调用函数（如
UUID()、NOW()）会引入非确定性，导致同一UPDATE在不同时间产生不同结果
别忽略BEFORE UPDATE触发器的“静默拦截”
BEFORE UPDATE触发器虽不改最终值，但能修改NEW值，从而让UPDATE写入一个你完全没预期的值。更麻烦的是：它可能基于业务规则“拒绝”更新——比如金额不能为负，就SET NEW.amount = OLD.amount，结果你update了，但数据库默默回退成旧值。
- 执行
SELECT * FROM information_schema.TRIGGERS WHERE EVENT_OBJECT_TABLE = 'users' AND EVENT_MANIPULATION = 'UPDATE'，确认EVENT_TIMING是BEFORE还是AFTER - 在
BEFORE触发器里搜索OLD.和NEW.的赋值关系，尤其关注条件分支（IF ... THEN SET NEW.x = OLD.x） - 测试时用
SELECT OLD.status, NEW.status FROM users WHERE id = 123无法直接看到OLD/NEW，得靠触发器日志或临时加INSERT INTO debug_log ...调试 - 若触发器逻辑复杂，优先在测试库用
SELECT模拟触发条件，验证其输出是否符合预期，再上线
真正难排查的从来不是触发器是否存在，而是它改了什么、什么时候改、改完还剩多少是你能控制的——每次怀疑触发器干扰，先停掉它跑一次，比读一百行SQL更快定位问题。
