最可控的日志方案是存储过程中用SYSDATETIME()打点+TRY...CATCH捕获错误：起始时间置于BEGIN TRY前，耗时用DATEDIFF(ms)计算，错误信息在CATCH内即时获取并写入含proc_name、start_time等字段的日志表。
直接在存储过程里用 SYSDATETIME() 打点 + TRY...CATCH 捕获错误，是最可控、不依赖外部配置的方式。其他方案要么查不到刚执行的记录（如 sys.dm_exec_procedure_stats），要么要开额外功能（如查询存储）、改权限（如 sp_OACreate），还可能被内存清理或事务隔离干扰。
SQL Server：用 SYSDATETIME() 和 ERROR_*() 埋点记日志表
这是生产环境最稳的组合：高精度起止时间 + 完整错误上下文。关键不是“能不能记”，而是“记什么”和“怎么防丢”。
-
DECLARE @start_time datetime2 = SYSDATETIME();必须放在BEGIN TRY前，否则异常跳过就测不准 - 结尾计算耗时用
DATEDIFF(ms, @start_time, SYSDATETIME())，单位毫秒，避免GETDATE()的 3.3ms 误差 -
ERROR_NUMBER()、ERROR_LINE()、ERROR_MESSAGE()这些必须在CATCH块里立刻取，出块就失效 - 日志表字段至少含：
proc_name（用OBJECT_NAME(@@PROCID)动态取）、start_time、duration_ms、error_number、error_message、error_line - 别只写成功路径——失败时也要 INSERT，否则断档；可在
CATCH末尾补一条INSERT记录
MySQL：用 NOW(6) + GET DIAGNOSTICS 替代 PRINT
MySQL 没有 TRY...CATCH，也没 ERROR_*() 函数，得靠 DECLARE HANDLER 和诊断区手动捞错。而且 SELECT 调试会干扰调用方结果集，必须收束。
- 起始时间用
DECLARE start_ts TIME(6) DEFAULT NOW(6);，结束用TIMEDIFF(NOW(6), start_ts)，注意TIMEDIFF最大支持 838:59:59，超时会截断 - 错误捕获必须用
DECLARE EXIT HANDLER FOR SQLEXCEPTION，然后立即执行GET DIAGNOSTICS提取RETURNED_SQLSTATE、MYSQL_ERRNO、MESSAGE_TEXT -
SELECT只能用于调试，且必须是存储过程**最后一个语句**；上线前删掉或注释，否则业务代码解析结果集会出错 - 更稳妥的做法是建日志表，用
INSERT写入，而不是依赖客户端看到的SELECT输出
PostgreSQL：用 CLOCK_TIMESTAMP() + RAISE LOG 避免事务时间偏移
NOW() 返回的是事务启动时间，在长事务里会失真；CLOCK_TIMESTAMP() 是真实系统时间，不受事务影响。错误记录也得绕开只读事务限制。
- 开头写
DECLARE start_ts TIMESTAMPTZ := CLOCK_TIMESTAMP();，结尾用EXTRACT(EPOCH FROM (CLOCK_TIMESTAMP() - start_ts)) * 1000000得到微秒级耗时 - 函数定义必须显式声明
VOLATILE，否则默认STABLE会禁止写日志表 - 写日志表前确认已授权：
GRANT INSERT ON TABLE public.proc_log TO your_function_owner; - 别在
EXCEPTION块里再抛新异常后尝试写日志——事务若已回滚，INSERT直接失败
所有方案里最容易被忽略的，是日志表本身的结构设计：没加 proc_name 字段就查不出哪个过程慢；没存 start_time 就没法按时间范围筛选；没把 ERROR_LINE() 或等效字段落库，定位具体哪行出错就得翻源码。这些不是锦上添花，是排查链路的第一环。
