SQL Server 日志埋点应剥离主事务，推荐 sp_trace_generateevent（2016 及以下）或扩展事件（2017+）；PostgreSQL 用 RAISE LOG 配 log_min_messages=’log’；MySQL 需透传 @caller_proc 等变量构建调用链；通用字段仅需 start_time、end_time、input_hash、err_code。
SQL Server 存储过程中怎么加日志埋点不卡死
直接写 INSERT INTO log_table 很容易拖慢主流程，尤其在高并发或事务里。核心是把日志写操作从主事务中剥离，又不能丢数据。
推荐用 sp_trace_generateevent（轻量、异步、不阻塞）或 sys.dm_exec_sessions + 外部轮询方式；如果必须落库，得走 WITH (TABLOCK, NOLOCK) + 独立事务，且日志表必须有合适索引（只按 log_time 或 proc_name 建非聚集索引）。
- 别在事务里直接
INSERT日志——会延长锁持有时间，引发阻塞 - 避免用
GETDATE()做日志主键或唯一约束字段——高并发下易冲突 -
sp_trace_generateevent只支持 SQL Server 2005–2016，2017+ 应改用扩展事件（CREATE EVENT SESSION），但注意默认不捕获自定义文本
PostgreSQL 函数里记录执行步骤的最小代价方案
用 RAISE LOG 是最省事的，它走的是服务器日志管道，不进数据库表，也不参与事务回滚。但默认不会输出到你习惯看的地方，得配 log_destination 和 client_min_messages。
常见错误是只改了 postgresql.conf 的 log_statement = 'mod'，结果还是看不到函数内日志——那是因为 RAISE LOG 默认级别低于 log_min_messages（通常是 warning），得显式设成 log_min_messages = 'log' 或更低。
-
RAISE LOG 'step %, id=%', step_num, input_id;—— 支持格式化，无性能压力 - 别用
RAISE NOTICE埋点——客户端可能过滤掉，且部分 ORM 会吞掉这类消息 - 如果要用表存日志，务必用
UNLOGGED TABLE+ 批量写入（比如每 10 步合一次INSERT …… VALUES (……), (……)）
MySQL 存储过程日志无法回溯调用链怎么办
MySQL 没有内置调用栈记录，SHOW PROCEDURE STATUS 只能看到最后执行时间，没法查“谁在什么时候传了什么参数调了我”。得靠人工打点 + 上下文透传。
关键是在每个被调用的存储过程开头，立刻把调用方信息存进线程级变量，比如 @caller_proc、@call_depth、@trace_id。再配合日志表里的 thread_id 字段，就能串起一条链。
- 用
SELECT CONNECTION_ID()获取当前连接 ID，作为日志表的thread_id字段值，比@@pid更准 - 别依赖
@@PROCEDURE_NAME这类不存在的变量——MySQL 不提供运行时过程名反射 - 如果过程嵌套深，
@call_depth := @call_depth + 1要放在DECLARE后第一行，否则可能被优化掉
所有数据库通用的日志字段设计避坑点
不是字段越多越透明。加了 error_stack 却没开 max_error_count，或者记了 exec_time_ms 却没对齐时钟源，日志就变成干扰项。
真正有用的字段只有四个：入口时间（start_time）、结束时间（end_time）、输入摘要（input_hash，不是明文）、错误码（err_code，不是 err_message）。其余像 host、user、db_name 全部从连接上下文取，不靠应用层传。
-
input_hash用MD5(CONCAT_WS('|', p_param1, p_param2))，避免长文本拖慢插入 - 别在日志表里建
FULLTEXT索引——搜索靠外部 ELK 或 pg_search，库内只做等值和范围查 - MySQL 的
TIMESTAMP类型默认带时区转换，跨服务器部署时要统一设为TIMESTAMP WITHOUT TIME ZONE（5.6+ 支持）或全用BIGINT存毫秒时间戳
日志字段一旦上线就很难改，尤其是加了索引的字段。上线前拿真实流量压测写入吞吐，比想名字重要得多。
