应从NEW.amount直接读取新插入订单金额，不可查表；因记录未落盘，SELECT查询无效，且字段名须与表定义严格一致。
触发器里怎么拿到新插入订单的金额
触发器运行时，NEW 是唯一能访问刚插入/更新行数据的对象。校验订单金额必须从 NEW.amount（或你表中实际字段名，比如 NEW.total_price）读取，不能查表——此时记录还没落库，查不到自己。
常见错误是写成 SELECT amount FROM orders WHERE id = NEW.id，这在 BEFORE INSERT 里会返回空，因为行尚未写入；在 BEFORE UPDATE 里虽能查到旧值，但没必要绕路，直接用 NEW.amount 更安全。
- 字段名必须和表定义完全一致，大小写敏感（取决于数据库配置）
- 如果金额字段允许
NULL，要先判断：IF NEW.amount IS NULL THEN ... - 浮点数比较别用
=，改用范围判断，比如NEW.amount
校验失败时如何阻止插入并报错
不同数据库语法差异大，核心是让触发器“中断执行并抛出明确错误”。MySQL 用 SIGNAL SQLSTATE '45000'，PostgreSQL 用 RAISE EXCEPTION，SQL Server 用 THROW。
关键点：不能只写 SELECT '金额非法' 或 SET @msg = '...'，这些不会终止操作，插入照样发生。
- MySQL 示例：
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '订单金额必须大于0';
- PostgreSQL 示例：
RAISE EXCEPTION '订单金额不能为负: %', NEW.amount;
- SQL Server 示例：
THROW 50000, '金额必须在0.01~999999.99之间', 1;
要不要在UPDATE里也校验？
要，而且必须单独写一个 BEFORE UPDATE 触发器，或在一个触发器里用 IF (TG_OP = 'UPDATE') 分支处理。因为 INSERT 和 UPDATE 的触发时机、可访问变量（OLD vs NEW）都不同。
典型场景：用户修改订单金额后绕过前端校验，直接跑 SQL 更新。不校验的话，脏数据就进去了。
- UPDATE 场景下，建议同时检查变化量，比如
NEW.amount - OLD.amount > 10000可能是异常调账 - 避免在触发器里调用存储过程做复杂校验——会显著拖慢写入性能
- 如果业务要求“金额变更需审批”，触发器只做基础合法性检查（正数、精度、范围），审批逻辑放应用层
为什么不用CHECK约束而选触发器
因为 CHECK 约束无法跨表查询或调用函数，而真实校验常需要关联其他表。例如：“订单金额不能超过客户信用额度”，就得查 customers 表的 credit_limit 字段。
但注意：触发器里查其他表有风险。MySQL 的 BEFORE INSERT 触发器不允许对本表做 SELECT（会报错），但可以查其他表；PostgreSQL 允许，但可能引发锁竞争。
- 跨表校验务必加索引，否则每笔订单都扫一次客户表，QPS 上不去
- 避免在触发器里写事务控制语句（如
COMMIT），会破坏主事务一致性 - 测试时一定要用并发压测，单线程看不出死锁或性能拐点
触发器不是银弹，它把校验逻辑沉到数据库层，维护成本高、调试难。上线前得确认 DBA 允许，且应用日志能捕获到触发器抛出的错误码。
