无法在标准sql触发器中可靠区分手动修改与系统接口修改，因触发器不接收调用来源信息，主流数据库均无application_name等上下文字段；必须由应用层显式传递来源标识，如会话变量、注释或新增modified_by字段。
无法在标准 SQL 触发器中可靠区分手动修改与系统接口修改。 触发器本身不接收调用来源信息，MySQL、SQL Server、PostgreSQL 等主流数据库的触发器上下文里都没有 application_name、client_host 或类似字段可直接读取。所谓“精准区分”，本质上是个伪需求——除非你主动把来源信息带进来。
为什么触发器看不到是谁改的数据？
触发器是数据库层的自动响应机制，它只感知 INSERT/UPDATE/DELETE 操作本身，不关心上层是 MySQL Client、Python 的 pymysql、Java 的 JDBC、还是运维人员敲的 mysql -u root -p。数据库协议层面不向服务端透传“操作发起方身份”这类元数据。
常见误解包括：
- 以为
USER()或CURRENT_USER()能区分应用和人——其实它们只返回登录账户，比如都是app@10.0.1.%，根本看不出是 cron 脚本还是 DBA 手动执行 - 以为
CONNECTION_ID()有用——它只是连接编号，会复用、不可跨语句追踪，且触发器里不能查information_schema.PROCESSLIST（MySQL 报错Can't reopen table） - 寄希望于
SIGNAL或错误堆栈——触发器内无法获取调用栈，也没有CALLER_CONTEXT这类变量
真正可行的替代方案：让应用层显式声明来源
必须由业务代码配合，在 SQL 中注入可识别的标记。这不是“绕过限制”，而是符合数据库职责边界的合理设计。
- 在所有 INSERT/UPDATE/DELETE 语句末尾加注释，例如：
UPDATE orders SET status='shipped' WHERE id=123 /* source=erp_batch */；MySQL 5.7+ 会保留注释，但触发器里仍读不到——所以这招只适用于审计日志表（靠general_log或代理层捕获），不能用于触发器内判断 - 使用会话级变量传递标识：
SET @modify_source = 'inventory_sync'; UPDATE products SET stock = stock - 1 WHERE id = 456;；然后在触发器中读@modify_source——但注意：BEFORE UPDATE中可用，AFTER中可能因事务隔离失效；且该变量对其他并发连接不可见，安全但需应用严格遵守 - 新增一个字段如
modified_by（VARCHAR(32)），要求所有写入都填值：INSERT INTO orders (...) VALUES (... , 'payment_service');；触发器通过NEW.modified_by判断，最稳定，但需改造所有写入口
哪些做法看似聪明实则危险？
有人尝试在触发器里查 performance_schema.events_statements_current 或拼接 PROCESSLIST，结果不是权限不足就是死锁。更隐蔽的坑是：
- 在触发器中调用
SELECT USER(), CURRENT_USER()并据此跳过逻辑——这会让 DBA 手动修复数据时意外被绕过校验，反而破坏一致性 - 依赖客户端 IP 做判断：
HOSTNAME()在容器/K8s 环境下全是localhost或内部 DNS 名，毫无区分度 - 用时间窗口粗略判断：“凌晨2点的更新大概率是定时任务”——业务上线、故障回滚、灰度发布都会打破这个假设
最易被忽略的一点：哪怕你用尽所有技巧让触发器“感知”到来源，只要业务 SQL 绕过你的约定（比如直连 root 账户执行），整个机制就彻底失效。真正的控制点永远在应用层接入规范，而不是寄望触发器能读懂人心。
