关键配置字段必须用 BEFORE UPDATE 触发器硬拦截，因其可防御运维SQL、旧服务直连、SQL注入等绕过应用校验的情况；触发器仅校验禁止修改字段，不查表、不调函数，且需配合DELETE/INSERT触发器及权限管控。
MySQL 里用 BEFORE UPDATE 触发器拦截非法配置修改
直接结论：关键配置表（比如 system_config）的字段如 pay_timeout、max_retry_count，不能靠应用层校验兜底，必须在数据库层用 BEFORE UPDATE 触发器硬拦截。
为什么？因为运维手动执行 SQL、旧版服务直连 DB、甚至 SQL 注入绕过 ORM 校验，都可能跳过应用逻辑。触发器是最后一道物理防线。
- 只对明确禁止修改的字段设条件，比如
IF OLD.status != NEW.status THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'status is read-only'; END IF; - 避免在触发器里查其他表或调用函数——会拖慢所有
UPDATE，且 MySQL 8.0 前不支持触发器内事务控制 - 触发器不会阻止
DELETE或INSERT，如果业务上也不允许新增/删除配置行，得额外加BEFORE DELETE和BEFORE INSERT - 注意权限：创建触发器需要
TRIGGER权限，线上账号常被限制，部署前确认 DBA 是否放行
PostgreSQL 怎么实现等效保护（不用触发器）
PostgreSQL 更推荐用 ROW LEVEL SECURITY (RLS) 策略配合 SECURITY DEFINER 函数，比触发器更轻量、更易审计。
常见错误是直接给应用用户 UPDATE 权限——一旦开了，就等于放弃控制权。正确做法是收走直接 DML 权限，只开放自定义函数。
- 建一个
update_config_safe()函数，用SECURITY DEFINER模式，内部做字段白名单校验和变更日志写入 - 撤掉应用用户对
config_table的UPDATE权限，只授EXECUTE给该函数 - RLS 策略可作为第二层：比如
USING (current_user = 'config_admin')，让非管理员连 SELECT 都看不到敏感字段 - 注意：函数内不能用
RETURNING直接返回新值，需显式SELECT，否则应用层拿不到更新结果
触发器里怎么记录谁改了、改了什么
光拦截不够，生产环境必须留痕。但别在触发器里直接写日志表——容易死锁，尤其高并发时。
安全做法是把变更信息塞进临时表或用 INSERT ... SELECT 写入带 DELAYED（MySQL）或异步队列（PG），但更稳的是交给应用层补日志。
- 触发器里只做最简记录：插入一条到轻量日志表，字段仅含
table_name、pk_id、old_value、new_value、updated_by（从USER()或CURRENT_USER取） - 不要存完整 JSON 差异——MySQL 触发器不支持 JSON 函数，PG 虽支持但会显著拉长锁持有时间
- 日志表引擎选
ARCHIVE（MySQL）或UNLOGGED（PG），避免 WAL 压力过大 - 如果业务要求精确到 IP 和应用名，得靠应用在 SQL 里显式传参，比如
SET @app_context = 'order-service-v2'，再在触发器里读@app_context
哪些配置不适合用触发器硬锁
不是所有“关键配置”都适合一刀切禁止修改。比如灰度开关、降级开关这类字段，必须能快速生效，硬锁反而阻碍故障响应。
真正该锁的是那些修改后需重启服务、或影响全局一致性、或有强依赖上下游的字段，例如加密密钥、分库分表路由规则、核心超时阈值。
- 区分字段粒度：同一张表里，
is_maintenance_mode可放开，但crypto_key_v1必须锁 - 避免用触发器做业务逻辑判断，比如“只有状态为 draft 才能改”，这种应由应用控制流程，触发器只管“绝对不可改”的底线
- 测试环境要关掉这些触发器——否则自动化测试跑不起来，但别用
DROP TRIGGER，用DISABLE TRIGGER（PG）或注释掉（MySQL）更可控 - 上线前务必验证：用低权限账号执行
UPDATE，确认报错是预期的SQLSTATE或消息，而不是触发器语法错误导致静默失败
最麻烦的其实是跨库场景——比如配置存在 Redis + MySQL 双写，触发器只拦住 MySQL，但应用仍可能直写 Redis。这时候得靠统一配置中心（如 Apollo/Nacos）收口，数据库触发器只是其中一环。
