MySQL触发器无法获取真实调用程序名，USER()和CURRENT_USER()返回的是连接用户而非客户端程序，唯一可靠上下文是NEW/OLD伪记录和触发事件类型。
MySQL 触发器无法直接获取调用它的客户端程序名或 SQL 上下文来源。 它没有类似 USER() 那样能暴露调用方身份的内置变量，也没有 PROGRAM_NAME、CURRENT_CLIENT 这类标准字段。所谓“判断由哪个程序调用”，本质是误判了触发器的能力边界。
为什么不能用 USER() 或 CURRENT_USER() 判断调用方
这两个函数返回的是当前连接的数据库用户（如 'app_user@10.0.1.5'），不是发起原始 SQL 的应用进程。哪怕 Java、Python、Node.js 用同一个账号连库，USER() 输出完全一样，无法区分。
-
USER()包含主机地址，但通常来自连接池或代理（如 ProxySQL、HAProxy），实际是中间层 IP，不是终端程序 -
CURRENT_USER()更严格，只反映权限匹配的账户定义，连主机部分都可能被省略 - 两者在触发器中可用，但对“是谁调用了这条 INSERT”毫无帮助
真正可观察的上下文线索只有 NEW/OLD 和事件类型
触发器唯一可靠的输入，就是它绑定的表操作本身：NEW 和 OLD 伪记录，以及触发时机（BEFORE/AFTER + INSERT/UPDATE/DELETE）。所有逻辑必须基于这些构建：
- 想区分“是后台定时任务更新 price，还是前端下单更新 status”？只能靠字段值变化模式，比如检查
NEW.status != OLD.status AND NEW.updated_by IS NULL推测为自动任务 - 想拦截非法修改？用
IF NEW.created_at - 想记录操作来源？必须提前在业务 SQL 中显式写入标识字段，例如
INSERT INTO orders (..., source_tag) VALUES (..., 'mobile_app_v2.3')，再在触发器里读NEW.source_tag
常见错误：试图用 INFORMATION_SCHEMA 或 performance_schema 反查
有人尝试在触发器里查 performance_schema.events_statements_current 或 INFORMATION_SCHEMA.PROCESSLIST，这会失败：
- 触发器执行时，原始语句在
events_statements_current中已结束或不可见，查不到上下文 - 访问
PROCESSLIST需要PROCESS权限，且结果不稳定——同一连接可能并发多条语句，无法精准绑定到当前触发行 - MySQL 8.0+ 默认禁用
performance_schema对触发器线程的采集，查出来是空或过期数据
替代方案：把“来源信息”变成数据契约的一部分
如果业务上真需要区分调用方，正确做法是让上游程序负责传递，而不是让触发器去猜：
- 在表结构中增加
source_app VARCHAR(32)、trace_id CHAR(16)等字段，由应用层填值 - 用存储过程封装写入逻辑，把来源作为参数传入，再由存储过程内部调用 INSERT 并触发器响应
- 借助 MySQL 8.0 的
SET_VAR提示（如INSERT /*+ SET_VAR(cte_max_recursion_depth=10) */ INTO ...），但该机制不支持自定义元数据，无法传递应用标识
最常被忽略的一点：触发器是数据库层的自动响应机制，不是审计日志代理。需要溯源时，应优先启用 general_log 或 audit_log 插件，而非强求触发器承担它做不到的事。
