如何编写SQL存储过程性能对比_记录执行时间评估优化效果-SQL-PHP中文网

应使用数据库内置高精度时间函数在存储过程内部手动打点计时：sql server用sysdatetime()，mysql用now(6)，postgresql用clock_timestamp()，并统一转utc存储，避免外部工具、低精度函数或事务影响导致测量失真。

如何编写sql存储过程性能对比_记录执行时间评估优化效果

SQL Server 里怎么测存储过程真实执行时间

别信 SSMS 右下角那个“已用时间”，它只算网络往返+解析+显示耗时，不是存储过程实际运行时间。真要对比优化效果，得在过程内部掐秒表。

推荐用 SYS.DM_EXEC_SESSIONS 结合 GETDATE() 或更精确的 SYSDATETIME() 手动打点，尤其当过程含多次查询、循环或等待时，外部工具根本抓不准瓶颈在哪次调用。

用 DECLARE @start DATETIME2 = SYSDATETIME(); 开头，SELECT DATEDIFF(MICROSECOND, @start, SYSDATETIME()) 结尾，单位微秒，够细
避免用 GETDATE()（精度仅 3.3ms），高并发或短耗时过程下误差明显
如果过程里有 WAITFOR 或远程调用，必须把打点放在 EXEC 前后，否则测的是“发起时间”而非“执行时间”

MySQL 存储过程中记录执行耗时的可行方案

MySQL 没有内置高精度计时器，NOW(6) 是唯一能到微秒级的函数，但要注意：它在存储过程中被调用时，可能因事务隔离级别或复制延迟产生偏差。

实操上更稳的方式是用 BENCHMARK() 配合日志表，或者干脆把耗时记录逻辑移到应用层——毕竟 MySQL 存储过程本身调试和监控能力弱，硬塞计时反而增加复杂度。

若坚持在过程内记录，用 DECLARE start_time TIME(6) DEFAULT NOW(6); + TIMEDIFF(NOW(6), start_time)，但注意 TIMEDIFF 最大支持 838:59:59，超时会截断
别用 UNIX_TIMESTAMP() 做差值——它返回秒级整数，丢失全部亚秒精度
写入日志表时加 INSERT INTO perf_log(proc_name, duration_us) VALUES ('xxx', ...)，避免用 SELECT 输出，否则会被客户端工具干扰计时

PostgreSQL 函数中避免 EXPLAIN ANALYZE 干扰真实性能

EXPLAIN ANALYZE 看起来方便，但它会强制重跑一次查询，且开启额外统计开销，结果比实际业务调用慢 10%–30%，不能直接当优化依据。

真要评估，应该用 pg_stat_statements 插件采集生产环境真实调用数据，或在函数里用 CLOCK_TIMESTAMP() 手动埋点——它不受事务时间影响，比 NOW() 更准。

在函数开头写 DECLARE start_ts TIMESTAMPTZ := CLOCK_TIMESTAMP();，结尾 RAISE NOTICE 'duration: %', EXTRACT(EPOCH FROM (CLOCK_TIMESTAMP() - start_ts)) * 1000000 || ' μs';
禁用 auto_explain 模块做例行分析，它会在每次慢查询时自动触发，干扰正常执行节奏
如果函数调用了其他函数，CLOCK_TIMESTAMP() 在嵌套调用中依然有效，而 STATEMENT_TIMESTAMP() 会受事务起始时间影响，慎用

跨数据库统一记录执行时间的陷阱

想写个通用脚本对比不同库的存储过程性能？小心时间函数语义不一致：SYSDATETIME()（SQL Server）、NOW(6)（MySQL）、CLOCK_TIMESTAMP()（PostgreSQL）看着像，但一个依赖系统时钟，一个依赖事务快照，一个受同步复制延迟拖累。

更麻烦的是，有些数据库（如 Oracle）的 SYSTIMESTAMP 默认带时区，跨服务器比对前必须转成 UTC 再计算差值，否则同一条语句在不同时区机器上显示耗时不同。

所有时间戳入库前统一转成 UTC，用 AT TIME ZONE 'UTC'（PostgreSQL）、SWITCHOFFSET(..., '+00:00')（SQL Server）、CONVERT_TZ(NOW(6), @@session.time_zone, '+00:00')（MySQL）
别把毫秒值存成 INT，MySQL 的 INT 有符号上限是 2147483647（约 24.8 天），长期运行过程可能溢出
最隐蔽的坑：某些 ORM 或连接池（如 PgBouncer）会复用连接并重置会话变量，导致 SET LOCAL 类计时开关失效，务必验证连接是否真的“干净”

真实环境里，存储过程执行时间波动常来自锁等待、磁盘 I/O 或计划缓存失效，光看 CPU 耗时没用。如果两次执行时间差一倍，先查 sys.dm_exec_requests（SQL Server）或 pg_stat_activity（PostgreSQL）里的 wait_type / wait_event，而不是急着改 SQL。