如何调试引发超时的SQL查询？附相关查询代码与表量说明

1 先排查最明显的逻辑错误 #

你提供的s2子查询中存在明显的条件矛盾：

AND view2.some_prefix = 'ABCD'
AND view2.some_prefix = 'EFGH'

同一个字段不可能同时等于两个不同的字符串，若不是笔误（本该用OR/IN），该子查询理论上应该返回空结果。如果实际运行没有快速返回空反而卡死，大概率是优化器判断条件错误生成了异常执行计划。
另外注意检查主查询的过滤条件，你示例中写的t2.some = 'FROM' AND t2.some = 'VN1'如果是真实逻辑，同样存在上述矛盾，需先修正过滤条件。

2 修正连接写法，避免隐式连接隐患 #

你当前用的是逗号分隔的隐式连接写法，可读性差且容易漏写关联条件导致笛卡尔积，建议改成显式INNER JOIN写法，示例：

-- s2子查询修改后示例
SELECT
    view2.some_id,
    SUM(view1.qty)
FROM someview view1
INNER JOIN someview view2 
    ON view1.lot = view2.some_id
WHERE
    view2.some_prefix IN ('ABCD', 'EFGH') -- 修正后的条件
GROUP BY view2.some_id

3 分步调试定位瓶颈 #

不要直接跑整个视图创建语句，按逻辑拆分逐一排查：

• 单独运行s1子查询，统计执行时间，确认是否是s1的聚合逻辑慢
• 单独运行修正条件后的s2子查询，先去掉SUM和GROUP BY，只查count(*)，确认关联后的数据量是否符合预期（如果关联后的数据量远大于两个表本身的行数，说明存在一对多重复关联的问题）
• 单独跑主查询中t2的过滤逻辑，确认过滤后剩余的行数，再逐步关联s1、s2，定位是哪一步引入的性能问题

4 检查索引覆盖情况 #

你当前的表数据量并不大，超时大概率是缺失关联/过滤字段的索引导致全表扫描：

• 检查view1.lot、view2.some_id这两个关联字段是否有索引
• 检查过滤字段view2.some_prefix、sometable.side、主查询中t2的过滤字段是否有索引
• 注意如果someview是视图而非实体表，需要检查视图底层依赖的实体表对应字段是否有索引，直接关联两次视图相当于底层查询执行两次，性能会大幅下降，建议尽量直接关联底层实体表代替关联视图。

5 查看执行计划定位问题 #

在SQL Developer中选中要执行的SQL，按F10即可生成执行计划，重点排查：

• 是否有大量的TABLE ACCESS FULL（全表扫描），对应补充索引即可
• 是否有CARTESIAN JOIN（笛卡尔积），出现这个说明关联条件漏写或者错误，需要修正连接逻辑
• 排序、聚合步骤的开销是否过高，如果聚合的数据量太大可以提前过滤数据再做聚合

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