用户验收阶段SQL查询超时无结果，集成测试正常，请排查

首先，咱们得先搞清楚为什么集成测试没问题，到UAT就卡壳了——核心原因大概率是数据量的变化+SQL本身的性能缺陷，集成测试里orders表可能只有几条数据，就算写法粗糙也能跑，但UAT里数据量上去后，原本的性能问题就被彻底放大了。

先说说原SQL的几个致命问题 #

1. 连接条件的函数转换导致索引失效
   你写的连接条件是：

   a.Minute between to_char(cast( b.Orderplaced as date),'hh24:mi:ss') and to_char(cast( b.Ordercompleted as date),'hh24:mi:ss')
   

   这里对orders表的Orderplaced和Ordercompleted字段做了cast+to_char的转换，Oracle完全没办法利用这两个字段上的索引（就算你提前建了索引也白搭），每次查询都得全表扫描orders表。如果UAT里orders有几万甚至几十万条数据，全表扫描的开销会直接爆炸。

2. 字符串比较的逻辑既低效又不准确
   Minutes表存的是HH24:MI格式的字符串（比如00:12），而orders转出来的是HH24:MI:SS（比如00:12:20），字符串的between比较是按字符逐个比对的，不仅效率远低于日期类型的比较，逻辑上也有坑——比如一个订单从00:12:50到00:13:10，原SQL的字符串比较会判断00:12 <= 00:12:50 <= 00:13吗？其实不会，因为字符串长度不一样，Oracle会补空格后比较，结果可能完全不符合你的实际统计需求。

3. 执行计划可能因为统计信息过期走了弯路
   集成测试时数据量小，Oracle可能选了合适的执行计划，但UAT数据量变大后，如果表的统计信息没更新，Oracle会误判数据分布，继续用低效的执行计划（比如嵌套循环而不是更适合大数据量的哈希连接）。

一步步解决的方案 #

1. 重构Minutes表，改用日期类型存储

把原来存字符串分钟的表改成存日期类型的每分钟起始时间，这样后续不用做字符串转换就能直接和订单时间比较：

-- 先备份旧表数据（如果需要保留），再删除旧表
drop table Minutes;
-- 重建表，用DATE类型存储分钟点
create table Minutes(Minute_Dt DATE); 
-- 插入当天的每分钟起始时间
insert into Minutes (Minute_Dt) 
select trunc(sysdate) + interval '1' minute * (level - 1) as minute_dt 
from dual connect by level <= 1440;
-- 给日期字段加索引，加速连接查询
create index idx_minutes_minutedt on Minutes(Minute_Dt);

2. 给orders表加合适的索引

针对订单的时间字段建索引，让Oracle能快速定位符合时间范围的订单：

create index idx_orders_placed_completed on orders(Orderplaced, Ordercompleted);

3. 修改查询语句，用日期范围做连接

把原来的字符串比较改成日期范围判断，逻辑更准确，也能利用索引：

select 
    to_char(a.Minute_Dt, 'HH24:MI') as Minute, 
    nvl(count(b.OrderID),0) as orders 
from Minutes a 
left join orders b 
    -- 核心逻辑：判断当前分钟和订单的时间区间有重叠
    on b.Orderplaced < a.Minute_Dt + interval '1' minute 
    and b.Ordercompleted > a.Minute_Dt
where a.Minute_Dt <= trunc(sysdate, 'MI') -- 直接用日期比较，不用转字符串
group by a.Minute_Dt 
order by a.Minute_Dt;

这个连接条件的逻辑是：订单的开始时间早于当前分钟的结束时间，且订单的结束时间晚于当前分钟的开始时间——这样就能准确统计出每个分钟内正在进行的订单数，比原来的字符串比较靠谱多了。

4. 更新表的统计信息

如果UAT环境的表统计信息过期，就算改了SQL和索引，Oracle可能还是选不到好的执行计划，所以要手动收集统计信息：

-- 替换成你的数据库用户名
exec dbms_stats.gather_table_stats(ownname => 'YOUR_USERNAME', tabname => 'ORDERS');
exec dbms_stats.gather_table_stats(ownname => 'YOUR_USERNAME', tabname => 'MINUTES');

额外排查点 #

如果做完上面的优化还是慢，可以检查UAT环境的数据库配置：比如PGA/SGA的内存是否足够，是否因为内存不足导致排序、哈希连接的开销过大；或者有没有其他锁表、资源竞争的情况。

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