在性能分析过程中，经常遇到性能瓶颈出现在SQL的情况，此类问题通常可以分为两大类场景，一是SQL自身性能差导致的慢，如索引缺失、索引失效、统计信息不准确、SQL过于复杂等；二是由于外部原因等待导致的SQL执行慢，如某些系统资源导致的等待、数据资源争用导致的会话阻塞等。
对于SQL慢的情况，通常可以采用会话跟踪+单独执行验证的方式进行分析。单独执行也就是将慢的SQL拿到plsql、ssms等客户端工具执行看其响应情况；会话跟踪即在SQL执行过程中使用DBSQLMonitor工具跟踪数据库会话，查看SQL执行时段的会话状态及等待类型。
跟踪思路：
（1）问题跟踪
开启DBSQLMonitor，设置跟踪所有会话，监控时间间隔5s，如果目标SQL单次执行耗时较短，可以通过缩短监控时间间隔或多次验证方式进行跟踪。
此处以DBSQLMonitor为例进行示例。对于无法使用DBSQLMonitor工具的环境，在问题跟踪过程中，通过多次手动查询DB会话也可以实现相同目的。
（2）问题分析
对于SQL慢的情况，只需关注running/active状态的会话即可，因此，可以直接过滤status状态为active，并选择执行SQL相关的进程名称。然后查找关注的SQLText即可。
找到目标SQL对应的会话之后，检查会话状态即日志中的Blocked列，如果blocked列为0的话，表示当前会话未被阻塞；blocked列不为0，则表示当前会话被blocked列所示值的会话阻塞，如此依次查找直至找到阻塞其他会话，且自身未被其他会话阻塞的即为阻塞源。找到阻塞源后，进一步检查阻塞源会话状态，如果阻塞源会话为running/active等执行中状态，则表示阻塞源会话相关SQL执行慢导致，后续需进一步分析阻塞源SQL慢的原因；如果阻塞源会话为sleeping/Inactive等空闲状态，则表示阻塞源会话SQL已经执行完，但是其所在事务未提交，后续需从事务角度检查是否存在事务未提交等问题。
如果目标SQL对应的会话未被阻塞，则需要结合等待类型进一步分析，会话等待类型对应会话日志中对应的是lastWaittype列。由于每种数据库等待类型较多，此处不再详细列举，可以直接复制等待类型，查询相关类型含义即可。
（3）SQL优化
针对（2）分析结论，如果涉及资源瓶颈或数据库配置导致的SQL执行慢，则联系客户或数据库运维团队协助处理即可。
对于SQL自身性能差导致的执行慢的场景，则可以检查下索引是否完整、有效、统计信息是否过旧等。如通过索引等手段优化无效，则建议考虑对SQL进行等价改写，降低SQL复杂度。
常见数据库会话查询脚本：https://www.cnblogs.com/wang-xiaohui/p/14613312.html