应使用数据库专用性能监控机制而非 SYSDATE/NOW()测 SQL 执行时间：MySQL 8.0+ 查 performance_schema.events_statements_history_long 的 TIMER_WAIT；PostgreSQL 用 EXPLAIN (ANALYZE)；Oracle 开启 SQL_TRACE 并用 tkprof 解析；开发阶段优先使用客户端工具显示耗时。
SQL 查询执行时间怎么测，别用 SYSDATE 或NOW()直接减
想靠前后两个SYSDATE（Oracle）或NOW()（MySQL）相减来算查询耗时，基本不准。它们返回的是语句开始执行那一刻的时间戳，不是“执行中”的动态值；更关键的是，SQL 引擎通常会把这类函数提前求值、缓存甚至下推，导致两次调用实际拿到的是同一个时间点。
实操建议：
- MySQL 8.0+ 直接查
performance_schema.events_statements_history_long，过滤你的 SQL 文本，看TIMER_WAIT字段（单位皮秒） - PostgreSQL 用
EXPLAIN (ANALYZE, BUFFERS)，末尾会显示实际运行时间，比如Execution Time: 12.456 ms - Oracle 需开启 SQL trace：
ALTER SESSION SET SQL_TRACE = TRUE;，再跑查询，最后用tkprof解析 trace 文件 - 开发阶段临时测，用客户端工具（如 DBeaver、DataGrip）自带的执行耗时显示，比自己写函数靠谱得多
为什么 SYSDATE 在 Oracle 里不能当计时器用
SYSDATE 是语句级快照——整条 SQL 执行过程中，无论你在 WHERE、SELECT 还是子查询里反复调用它，返回的都是解析开始时那个瞬间的时间。它不随执行进度变化，也不反映真实耗时。
常见错误现象：
- 写
SELECT SYSDATE - :start_time FROM DUAL想测耗时，结果永远是 0 或极小值 - 在 PL/SQL 循环里多次取
SYSDATE做差，发现差值为 0，误以为没耗时（其实是毫秒级以下，SYSDATE精度只有秒） - 用
SYSDATE记录日志时间戳，却发现同一批处理记录的时间全一样
真正需要高精度计时，得用 DBMS_UTILITY.GET_TIME（单位：百分之一秒）或 DBMS_PROFILER。
MySQL 的 NOW() 和CURRENT_TIMESTAMP()到底有没有区别
在绝大多数场景下，NOW() 和 CURRENT_TIMESTAMP() 完全等价，都是语句开始执行时的时间快照，且都受事务隔离级别影响：在 REPEATABLE READ 下，同一事务内多次调用返回相同值。
容易踩的坑：
- 误以为
NOW()是“实时更新”，在触发器或存储过程中用来做微秒级顺序判断，结果逻辑错乱 - 用
NOW()生成唯一标识（比如拼接订单号），并发高时撞值——它不保证唯一性，也不够精细 - 想靠
NOW(6)（带微秒）测耗时？不行。它仍是语句级快照，只是精度更高，不代表执行中动态刷新
真要微秒级时间，MySQL 8.0+ 可用 SYSTIMESTAMP（如果启用了 system_time_zone 支持），但依然不能用于计时，仅作记录用。
跨数据库测执行时间，最稳的方案是什么
没有银弹，但有一条铁律：别依赖 SQL 内部函数做耗时测量。数据库自身执行计划、缓存机制、锁等待都会让“函数差值”失去意义。
推荐做法：
- 应用层控制：在代码里用
System.nanoTime()（Java）、time.perf_counter()（Python）包住数据库调用 - 数据库代理层介入：如使用 ProxySQL、pgBouncer，开启慢日志并提取耗时字段
- 监控系统采集：Prometheus +
mysqld_exporter或postgres_exporter，查mysql_global_status_commands_total类指标配合响应时间直方图 - 避免在生产 SQL 里硬编码计时逻辑，尤其别用
SYSDATE或NOW()做条件或排序依据——它们不是时钟，是快照
最常被忽略的一点：网络往返时间（RTT）和连接池等待时间，往往占到总耗时的 30% 以上，而这些完全不在 SQL 执行时间统计范围内。
