最稳方式是用after update触发器配合original_login()兜底，updated_by用sysname类型，需加if update判断防递归，避免复杂逻辑。
SQL Server 里怎么自动填 updated_by 字段？
靠应用层写死用户名不靠谱，一出错就全乱；用 CURRENT_USER 或 SUSER_SNAME() 倒是可以，但得每个 UPDATE 语句手动加，漏一个就断链。最稳的方式是用 AFTER UPDATE 触发器，在数据库层兜底。
触发器能拿到执行上下文里的登录名，哪怕应用用了连接池、统一账号，也能通过 ORIGINAL_LOGIN() 拿到真实操作人——这个函数比 SUSER_SNAME() 更准，它不随 EXECUTE AS 切换而变。
-
updated_by字段类型建议用sysname（等价于nvarchar(128)），别用varchar(50)，Windows 登录名可能超长 - 触发器里必须加
IF UPDATE(updated_at)判断，否则自更新时间字段也会触发，造成无限递归 - 别在触发器里做复杂逻辑（比如查用户表补全姓名），IO 和锁会拖慢所有
UPDATE
MySQL 8.0 怎么让 modified_by 自动更新？
MySQL 不支持 AFTER UPDATE 触发器里直接改 NEW 行（报错 Can't update table in stored function/trigger），所以不能像 SQL Server 那样“改完再存”。得换思路：用触发器只负责赋值，把更新动作交给主语句本身。
更实际的做法是，把 modified_by 改成 DEFAULT CURRENT_USER，然后要求所有 UPDATE 显式带上这个字段：
UPDATE orders SET status = 'shipped', modified_by = CURRENT_USER WHERE id = 123;
这听着反直觉，但比硬上触发器更可控。因为：
-
CURRENT_USER返回授权账号，USER()才返回连接账号——多数场景要的是后者，得用USER() - 如果应用用的是中间件或代理（如 ProxySQL），
USER()可能全是app@10.%，这时就得靠应用传入SET @app_user = 'zhangsan'，触发器读@app_user - MySQL 8.0.16+ 支持
SET PERSIST，但无法持久化会话变量，所以别指望靠全局变量兜底
PostgreSQL 的 current_user 和 session_user 该选哪个？
PostgreSQL 里 current_user 是当前执行权限所属角色，session_user 是连接时认证的角色。如果你用的是统一数据库账号 + SET ROLE 切换，那必须用 session_user，否则看到的全是 app_admin。
触发器写法简单，但有两处容易错：
- 触发器函数必须定义为
RETURNS trigger，且最后一行必须是RETURN NEW，漏了就导致整条记录被丢弃 - 别在触发器里调
CURRENT_TIMESTAMP更新时间，PostgreSQL 的DEFAULT NOW()已经够用，重复更新反而引发 MVCC 冗余版本 - 如果表启用了 RLS（行级安全策略），触发器在策略检查之后运行，但
session_user不受 RLS 影响，可放心用
触发器同步更新人字段，哪些坑会导致数据对不上？
最常踩的不是语法错，而是上下文理解偏差。比如开发测的时候用自己账号连数据库，一切正常；上线后应用走连接池，所有语句看起来都是 pool_user@localhost，updated_by 全变成同一个名字。
这类问题没法靠触发器本身解决，得配合架构调整：
- Java 应用可用
setClientInfo("ApplicationName", "order-service-zhangsan")，再在触发器里查current_setting('application_name', true) - Python 的
psycopg2连接时加options='-c application_name=xxx'，PostgreSQL 侧用current_setting('application_name')读取 - SQL Server 可以用
CONTEXT_INFO()，但要注意长度限制（128 字节），且需要应用每次请求前主动SET CONTEXT_INFO
说到底，数据库只认连接身份，不认业务身份。想精准溯源，得让应用把“谁在操作”这个信息，明确、稳定、低开销地透传进来——触发器只是最后一道落笔的手，笔尖蘸什么墨，得前面定好。
