【DM版本】:DM Database Server x64 V7.6.1.32-Build(2019.11.04-115241-debug)ENT DB Version: 0x7000a
【问题描述】*：这段sql语句，在生产环境使用时，前几个星期执行时候耗费几秒钟时间，但最近一段时间执行要耗费20多秒钟，主表alarm.yx_bw有38w条记录。

WITH yxbw28 AS (
SELECT yx_id, occur_time, status, st_id, content
FROM alarm.yx_bw
WHERE 1 = 1
AND occur_time >= ‘2020-04-24 00:00:00’
AND occur_time <= ‘2021-04-24 23:59:59’
AND status = 28
AND (content LIKE ‘%母接地%’
OR content LIKE ‘%母线接地%’)
),
yxbw27 AS (
SELECT yx_id, occur_time
FROM alarm.yx_bw
WHERE 1 = 1
AND occur_time >= ‘2020-04-24 00:00:00’
AND occur_time <= ‘2021-04-25 23:59:59’
AND status = 27
AND (content LIKE ‘%母接地%’
OR content LIKE ‘%母线接地%’)
),
z AS (
SELECT DISTINCT a.yx_id, a.content, a.st_id, a.occur_time
, (
SELECT MIN(b.occur_time)
FROM yxbw27 b
WHERE (b.occur_time) >= (a.occur_time)
AND b.yx_id = a.yx_id
) AS restore_time
FROM yxbw28 a
)

select * from z

这段sql要查的是同一个字段yx_id（非唯一）里，由status=28记录去匹配最近发生的一条status=27的记录。

yxbw28 和yxbw27表执行时间很快，过滤后有2.8w条记录。

执行计划看到统计有些问题，只有2567条

完整计划如下：

尝试通过
dbms_stats.gather_table_stats(ownname=>‘ALARM’, tabname=>‘YX_BW’, estimate_percent=> null ,method_opt => ‘for all indexed columns’ ,cascade => true);
更新表统计，还有SP_INDEX_STAT_INIT更新表索引，统计还是没有变化。

当时猜测是(b.occur_time) >= (a.occur_time)这段表达式耗时长，occur_time是timestamp类型，在本地环境（DM Database Server x64 V7.6.0.95-Build(2018.09.14-97154-debug)ENT）虽然本地测试表只有1w多条，但执行了几十秒钟时间，而通过函数unix_timestamp(b.occur_time) >= unix_timestamp(a.occur_time)执行只耗费2s，但在生产版本，加了这个函数反而耗费时间更长90s+之久，我更迷糊了。。。

附上执行时间：

请专家帮忙看看