Java应用中通过Apache QueryRunner记录SQL执行时间的意义与准确性探讨

一、应用端记录SQL耗时的核心价值 #

即便数据库、AWS自带SQL执行时间监控工具，应用端记录仍有不可替代的作用：

• 全链路性能视角：数据库侧仅记录SQL在库内的执行耗时，而应用端能覆盖从发起请求到拿到结果的完整链路——包含连接池取连接、参数填充、网络传输、结果解析、资源释放等所有环节，能帮你精准定位是数据库慢，还是应用或网络拖了后腿。
• 业务上下文关联：应用端可以把SQL耗时和业务日志（比如用户操作ID、请求ID）绑定，业务出问题时能直接定位到对应SQL，而数据库日志很难直接关联具体业务场景。
• 自定义监控灵活性：你可以基于应用日志自由设置告警规则，比如针对特定业务模块、特定SQL的耗时阈值告警，不用依赖数据库的监控配置，适配性更强。
• 多环境差异对比：在开发、测试、生产多环境下，应用端记录的耗时能直观反映不同环境的性能差异，比如连接池配置、网络延迟带来的影响。

二、基于QueryRunner重写的耗时记录准确性分析 #

结合你提供的重写代码和QueryRunner源码，这种记录方式的准确性要分维度看：

1. 覆盖的耗时范围 #

你的代码在调用super.update()前后计时，覆盖了：

• 连接池获取Connection的时间（prepareConnection()）
• PreparedStatement创建与参数填充（prepareStatement()、fillStatement()）
• SQL在数据库端的执行时间（stmt.executeUpdate()）
• Statement、Connection的关闭开销
• 应用侧方法调用的少量耗时

这记录的是应用发起SQL请求到完成资源释放的全链路耗时，而非纯数据库内的SQL执行时间。如果你的目标是监控端到端性能，这个范围很合理；但如果只想看数据库内部的SQL速度，这个数值会比数据库侧记录的大，因为包含了应用侧和网络的额外开销。

2. 针对MySQL、Redshift的细节差异 #

• MySQL：如果是同区域部署，网络延迟极低，应用端耗时和数据库慢查询日志里的Query_time差异主要来自连接池操作、参数填充。只要连接池配置合理（比如连接复用），这部分差异很小，能真实反映端到端性能。
• Redshift：作为云数据仓库，通常和应用跨网络部署，网络延迟占比可能很高。应用端记录的耗时会包含明显的SQL发送、结果返回的网络时间——这部分是数据库侧不会记录的，反而能帮你识别网络瓶颈。

3. 潜在误差点 #

• 时间精度：System.currentTimeMillis()是毫秒级，对于执行耗时小于1ms的SQL，记录精度不足，建议换成System.nanoTime()提升精度。
• 连接池干扰：如果连接池资源紧张，prepareConnection()获取连接的时间会占比很高，这部分耗时会被计入SQL执行时间，排查时要注意区分是连接池问题还是SQL本身的问题。
• 日志开销：logSqlWithTime()里的字符串拼接和日志输出有少量耗时，但相对于SQL执行、网络耗时可以忽略不计。

三、优化建议 #

• 若要区分数据库内部执行时间和应用侧开销，可以拆分计时：比如在stmt.executeUpdate()前后单独计时，同时保留全链路计时，既能看端到端耗时，也能知道纯数据库执行时间。
• 用System.nanoTime()替代System.currentTimeMillis()，适配短耗时SQL的精准记录。
• 日志中加入请求ID、业务模块标识，方便后续排查时关联上下文。

内容的提问来源于stack exchange，提问作者Alex