触发器中不能调用应用层费率逻辑，须将动态费率规则存入数据库rate_rules表并建立复合索引，仅BEFORE触发器可动态计算fee_amount，且需用COALESCE防空、ORDER BY LIMIT取最新规则，MySQL函数不可在触发器中调用含SQL的逻辑。
触发器里不能直接调用应用层费率逻辑
SQL 触发器运行在数据库内，无法访问 Python/Java 里的配置中心、远程 API 或缓存服务。所谓“动态费率”，必须把规则可配置化并落地到数据库表中，否则每次改费率都得改触发器代码——这反而违背了“不改动代码”的初衷。
典型做法是建一张 rate_rules 表，字段至少包含：product_id、start_date、end_date、base_rate、multiplier、is_active。触发器通过 JOIN 或子查询实时查这张表，而不是硬编码 0.05 或写死 CASE WHEN amount > 1000 THEN 0.08。
- 务必给
rate_rules加复合索引：(product_id, start_date, end_date, is_active)，否则每次 INSERT/UPDATE 都触发全表扫描 -
end_date建议用'9999-12-31'表示长期有效，避免 NULL 判断拖慢查询 - 触发器中禁止使用
SELECT ... INTO赋值多行结果，会报Subquery returns more than 1 row
BEFORE INSERT/UPDATE 触发器才能真正“动态计算”
只有 BEFORE 类型的触发器能修改即将插入或更新的行（比如重算 fee_amount 字段），AFTER 触发器只能做日志、通知或异步补偿，无法影响当前事务的数据结果。
例如订单表 orders 有 amount 和 fee_amount 字段，触发器逻辑应类似：
CREATE TRIGGER calc_fee_before_insert
BEFORE INSERT ON orders
FOR EACH ROW
BEGIN
DECLARE v_rate DECIMAL(5,4);
SELECT base_rate * multiplier INTO v_rate
FROM rate_rules
WHERE product_id = NEW.product_id
AND is_active = 1
AND CURDATE() BETWEEN start_date AND end_date
ORDER BY start_date DESC LIMIT 1;
SET NEW.fee_amount = ROUND(NEW.amount * COALESCE(v_rate, 0), 2);
END;- 必须用
COALESCE(v_rate, 0)，防止查不到规则时整个 INSERT 失败 -
ORDER BY start_date DESC LIMIT 1是为支持同一产品多个历史费率版本，取最新生效的 - 如果业务允许“无规则即拒绝”，就把
COALESCE换成显式判空并SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'No active rate rule found';
MySQL 8.0+ 支持触发器调用函数，但函数不能含 SQL
MySQL 的存储函数（CREATE FUNCTION）若声明为 READS SQL DATA，就不能在触发器中调用——这是 MySQL 的硬性限制，报错 This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA。
所以别试图把费率计算封装成函数再让触发器调用。可行路径只有两个：
- 把完整计算逻辑（含表连接、条件判断、四舍五入）全部写进触发器体内部
- 用视图（
VIEW）预定义好“订单+实时费率”关联结果，但触发器里仍不能直接SELECT FROM view（MySQL 不支持），只能复制视图里的SELECT逻辑
PostgreSQL 没这个限制，它的函数可安全被触发器调用，但迁移成本高，不是“不动代码”的解法。
触发器失效或性能崩塌的三个信号
一旦发现费率计算偶尔出错或批量导入变慢，先盯住这三个点：
- 触发器里用了
SELECT ... FROM other_db.table_name—— 跨库查询在某些 MySQL 版本会锁表或超时 -
rate_rules表没主键或没索引，导致每次触发都EXPLAIN显示type: ALL - 应用批量执行
INSERT INTO orders VALUES (...), (...), (...)，而触发器对每行都查一次rate_rules，QPS 翻三倍
复杂场景下，触发器只是兜底手段。真要支撑高频、多维、可灰度的费率策略，还是得把计算下沉到数据库前的轻量服务层——触发器只保留最简规则和熔断逻辑。
