在BEFORE UPDATE触发器中，通过OLD.列名 > NEW.列名判断数值变小，但需确保二者均非NULL；稳妥写法为IF OLD.amount IS NOT NULL AND NEW.amount IS NOT NULL AND OLD.amount > NEW.amount THEN，并写入专用日志表供外部消费。
触发器里怎么判断某列数值变小了
直接在 BEFORE UPDATE 触发器中比较 OLD.列名 和 NEW.列名 即可。注意必须是数值类型（如 INT、DECIMAL），字符串或 NULL 要额外处理。
常见错误是忽略 NULL：如果 OLD.列名 为 NULL，OLD.列名 > NEW.列名 整个表达式返回 UNKNOWN，不会触发后续逻辑。稳妥写法是显式排除：
IF OLD.amount IS NOT NULL AND NEW.amount IS NOT NULL AND OLD.amount > NEW.amount THEN
- 只监控明确有值的更新，避免误报
- 跌幅阈值建议用绝对差值或百分比，别只看“变小”——比如从 100 降到 99 不一定需要告警
- MySQL 不支持在触发器里直接发邮件或调外部服务，得靠写日志表 + 外部轮询
把跌幅记录到日志表而不是直接告警
触发器内不能执行 INSERT INTO ... SELECT 或调存储过程（某些 MySQL 版本限制），但可以安全写入一张专用日志表。这张表要包含足够上下文，否则查问题时抓瞎：
CREATE TABLE price_drop_log ( id BIGINT AUTO_INCREMENT PRIMARY KEY, table_name VARCHAR(64), row_id BIGINT, column_name VARCHAR(64), old_value DECIMAL(12,2), new_value DECIMAL(12,2), drop_amount DECIMAL(12,2), drop_percent DECIMAL(5,2), updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, processed TINYINT DEFAULT 0 );
-
row_id必须是原表主键值（比如OLD.id），方便回溯 -
drop_percent计算时加防除零：IF(OLD.amount != 0, ROUND((OLD.amount - NEW.amount)/OLD.amount*100, 2), NULL) - 别在触发器里加索引或
SELECT查询其他表——会拖慢所有UPDATE
为什么不能在触发器里直接发邮件或调 API
MySQL 触发器运行在事务上下文中，而发邮件、HTTP 请求这类操作不可回滚、不可预测，且违反 ACID 原则。多数生产环境会禁用 sys_eval 或 lib_mysqludf_sys 这类扩展函数。
真实可行路径只有两条：
- 写入日志表后，由外部脚本（Python/Shell）定时扫描
processed = 0的记录，发企业微信/钉钉/邮件，再更新processed = 1 - 用 MySQL 8.0+ 的
EVENT定期检查日志表，但 EVENT 本身也不能发 HTTP 请求，仍需配合外部消费 - 如果用 PostgreSQL，可用
pg_notify()配合监听程序，但 MySQL 没对应机制
监控多列或动态列名怎么办
触发器不支持变量列名，OLD.列名 中的“列名”必须硬编码。想覆盖多个列，只能写多个条件分支：
IF OLD.stock_qty > NEW.stock_qty THEN
INSERT INTO price_drop_log (...) VALUES ('inventory', OLD.id, 'stock_qty', ...);
END IF;
IF OLD.price > NEW.price THEN
INSERT INTO price_drop_log (...) VALUES ('inventory', OLD.id, 'price', ...);
END IF;- 每增一个监控列，就得改触发器并重新
CREATE TRIGGER - 别试图用
CONCAT('OLD.', col_name)动态拼接——语法错误，MySQL 不允许 - 如果列太多，说明设计可能有问题：考虑是否该拆成状态变更事件表，而不是靠触发器硬扛
真正难的不是写触发器，而是定义清楚“什么算有效跌幅”和“谁来消费日志”。业务规则一变，日志表结构、阈值、通知渠道全得跟着动，这部分没法藏在数据库里。
