MySQL和SQL Server触发器均无法自动识别调用者：MySQL无任何调用栈信息；SQL Server中@@PROCID返回自身ID，TRIGGER_NESTLEVEL()>1仅表明确为嵌套调用，具体过程名仍需调用方显式传参（如CONTEXT_INFO、临时表或业务字段）实现。
SQL触发器中无法直接获取调用它的存储过程名——这不是权限或写法问题，而是数据库引擎设计上的根本限制。MySQL 完全不提供调用栈信息；SQL Server 虽有部分上下文函数，但 @@PROCID 在触发器里返回的是触发器自身 ID，不是调用者。
MySQL 触发器里为什么查不到调用方？
MySQL 触发器运行时没有任何会话级“调用链”元数据。它只感知到 INSERT/UPDATE/DELETE 事件和 NEW/OLD 行数据，不记录语句来源是应用直连、CALL my_proc() 还是另一个触发器。
- 你不能在触发器里写
IF CURRENT_USER() = 'my_proc'或SELECT ROUTINE_NAME FROM INFORMATION_SCHEMA...来反推调用者 - 试图读取
performance_schema.events_statements_current也不可靠：该表按会话记录，但触发器执行时上下文已切换，且默认可能被禁用 - 唯一可行路径是：由调用方（如存储过程）主动把标识写进业务字段或临时表，触发器再去读
SQL Server 中 TRIGGER_NESTLEVEL() 能帮你判断嵌套层级
TRIGGER_NESTLEVEL() 返回当前触发器在调用栈中的深度，值为 1 表示由用户 SQL 直接触发（比如 SSMS 里手动执行 UPDATE），大于 1 表示来自存储过程、动态 SQL 或嵌套触发器。
- 若
TRIGGER_NESTLEVEL() > 1，说明大概率是某个存储过程触发的，但具体是哪个仍未知 -
OBJECT_NAME(@@PROCID)在触发器里返回的是触发器名，不是调用者名；想查调用者需依赖sys.dm_exec_input_buffer（需 VIEW SERVER STATE 权限）或提前在调用方写入CONTEXT_INFO - 更实用的做法：在存储过程中设置
SET CONTEXT_INFO 0x53716C536572766572（ASCII “SqlServer” 的十六进制），触发器里用CONVERT(VARCHAR(128), CONTEXT_INFO())读取——但要求调用方严格配合，且仅限同一会话
真正能落地的方案：让调用方显式传参
不要指望数据库自动识别“谁调用了我”，而应把识别逻辑前移到调用侧。这是跨 MySQL / SQL Server 都稳定有效的做法。
- 在存储过程中插入/更新前，往目标表加一个辅助字段，如
source_caller VARCHAR(64)，值设为'proc_update_order' - 触发器里检查
IF NEW.source_caller = 'proc_update_order'再分支处理，用完可清空或忽略 - 若不想改表结构，可用会话级临时表：
CREATE TABLE #caller_hint (name VARCHAR(64))，调用方插入一行，触发器查询并DROP TABLE #caller_hint（注意：临时表仅当前会话可见，且必须在触发器内显式清理） - 所有方案都依赖调用方守约——如果某段代码绕过存储过程直连更新，这个标识就失效了，所以需配套审计或权限控制
最易被忽略的一点：哪怕用了 CONTEXT_INFO 或临时表，也得考虑事务回滚场景。如果存储过程中途 ROLLBACK，临时表数据会消失，但触发器可能已执行——这意味着识别逻辑必须是幂等的，不能依赖状态强一致性。
