MySQL触发器无法获取真实调用来源，因其无上下文感知能力，必须由应用层或调用方显式传入标识（如@current_user_id、source_flag字段）并在触发器中用IFNULL兜底；SQL Server虽有TRIGGER_NESTLEVEL()等有限手段，但仍需主动配合，数据库层无自动回溯调用栈能力。
MySQL 里无法直接获取触发器调用来源
MySQL 的触发器本身不记录、也不暴露“是谁触发了我”——INSERT、UPDATE 或 DELETE 语句不管来自应用直连、存储过程、还是另一个触发器，对当前触发器来说都是一样的事件。它没有类似 @@PROCID 或 CURRENT_PROCEDURE() 这样的上下文变量。
这意味着你不能在触发器内部写 IF CURRENT_CALLER() = 'my_proc' 这类逻辑。所有触发来源都被抽象为“表上发生了某类 DML”，这是 MySQL 触发器的设计限制，不是权限或配置问题。
SQL Server 中可通过 TRIGGER_NESTLEVEL() 和调用栈间接判断
SQL Server 提供了有限的上下文感知能力：
-
TRIGGER_NESTLEVEL()返回当前触发器嵌套深度：值为 1 表示由用户 SQL 直接触发；大于 1 表示由存储过程、另一个触发器或动态 SQL 引起 - 结合
OBJECT_NAME(@@PROCID)可查到当前执行上下文对象名，但注意：在触发器中@@PROCID指向的是触发器自身，不是调用者 - 真正能定位调用方的方式是：在调用方（如存储过程）里显式传入标识，比如加一个
@caller_hint VARCHAR(64)参数，并在触发器里检查对应字段或临时表
例如，在存储过程中插入前写入临时表：INSERT INTO #trigger_caller VALUES ('proc_update_order')，再让触发器读取该临时表——但这要求调用方主动配合，且仅限同一会话。
通用替代方案：用业务字段或注释标记来源
当必须区分触发来源时，更可靠的做法是把意图“带进来”，而不是“问出来”：
- 在 INSERT/UPDATE 语句中显式设置一个标记字段，如
source_flag VARCHAR(20) DEFAULT NULL，调用方填'from_batch_job'或'from_api' - 利用 MySQL 的
USER()或CONNECTION_ID()辅助判断会话归属，但无法精确到具体 SQL 块 - 在 SQL Server 中，可借助
CONTEXT_INFO()：调用方先执行SET CONTEXT_INFO 0x53514C536572766572，触发器中用CONVERT(VARCHAR(128), CONTEXT_INFO())读取——需严格配对且不跨批次
这些都不是“自动识别”，而是靠协作约定。数据库层没有魔法 API 能回溯 SQL 文本来源。
为什么不能像调试一样看到调用栈
根本原因在于 DML 触发机制是声明式的、非栈式执行：MySQL 把触发器当作事件响应逻辑挂载在表上，SQL Server 的 DML 触发器也运行在独立执行上下文中。它们不继承调用方的堆栈帧，也不保存原始 SQL 文本。日志（如 general_log 或 SQL Server 的 XE）虽能记录原始语句，但触发器内部不可访问这些日志内容。
真正需要审计来源的场景，应优先考虑在应用层或中间存储过程里做标记，而不是指望触发器自省。
