导读：看SQL的执行效率，不难想到用explain来分析慢查询，但前提是你需要非常了解业务背景。否则很难准确定位。系统是逐渐演进的，一个系统在运行过程中，必须根据场景逐步完善和优化性能。高并发是对节省资源的考验。本次测试除了更换优秀先进技术、优化架构外，还在于从小处着手，尽可能节约资源。在一个系统的数据访问中，系统的瓶颈往往来自于数据库，所以我们应该尽量减少对数据库的访问！一、背景大家有没有遇到过这样的情况，领导突然安排了一个事情：这些接口的压测指标太低，需要针对性的优化。当然，理想情况下，你对业务场景非常熟悉，可以大致定位问题来分析业务，准确评估哪些SQL会出现性能瓶颈。然后开始百度：如何提高SQL执行效率？使用解释、显示配置文件和跟踪等诊断工具分析慢速查询。但在大多数情况下，业务线太长，一个人无法完成。涉及多种策略模式和监控动作。如果想直接定位到点，还需要在发起请求后输出执行的SQL和触发的执行效率。这里的效率只是指SQL执行的时间。目标明确后，我们就开始工作吧。2、添加JDBCtrace继续上一篇文章的主题：如何利用好loglinktrace进行性能分析？?SQL执行时间公式应对此类问题，首先分析，如何划分SQL执行时间的计算？SQL语句执行过程大致如下图所示。如果要统计SQL执行时间。所以对于程序，可以得到一个粗略的公式SQL执行时间=数据提取后的时间-语法分析开始时间?加入JDBC跟踪。看过Hibernate、MyBatis等持久化框架的应该对Statement比较了解。由java.sql基础包下的Statement提供。用于执行静态SQL语句并返回其产生的结果的对象。默认情况下，每个Statement对象一次只能打开一个ResultSet对象。因此，如果一个ResultSet对象的读取与另一个ResultSet对象的读取交织在一起，则每个对象必须由不同的Statement对象生成。Statement接口中的所有执行方法都会隐式关闭Statement的当前ResultSet对象（如果存在）。继续查看源码发现Statement提供了执行的方法后，PreparedStatement预编译了SQL语句对象。SQL语句被预编译并存储在PreparedStatement对象中。然后可以使用该对象多次有效地执行该语句。为了验证这个想法，可以参考其他定制的数据库驱动。定义StatementWraper实现Statement提供用于执行静态SQL语句并返回其产生的结果的对象。日志详细信息publicclassPreparedStatementWraperextendsStatementWraperimplementsPreparedStatement{privatePreparedStatementraw;私有字符串sql；publicPreparedStatementWraper(PreparedStatementraw,Stringsql){super(raw);这个.raw=raw;这个.sql=sql;}//==========日志记录==========@OverridepublicResultSetexecuteQuery()throwsSQLException{longstartTime=System.currentTimeMillis();尝试{返回raw.executeQuery();}最后{doLog("executeQuery",sql,startTime);}}....j最终的日志输出使用logback组件进行日志收集。这种问题之前介绍过。在微服务分布式架构中，如何实现日志链接跟踪？如何利用好日志链接跟踪进行性能分析？
