现象：门诊医生站运行都正常的情况，唯独肿瘤科查询未就诊病人信息出现超时的情况。
    处理过程：
    一、跟踪执行，拿到执行较慢的sql语句（过程中会拿到很多sql语句，需要所有手工自行一遍，找到较慢的），本次找到的sql语句如下，其他语句执行不足1s的情况下，此语句执行28s，现在是补充记录，无法提供最初的执行时间截图
    SELECT
    FROM (select n.
    from (SELECT M.*,
    row_number() over(partition by 门诊号 order by 门诊号) as group_idx
    FROM (SELECT A.BRID AS 病人ID,
    A.ID 挂号单ID,
    B.ICNO AS 卡号,
    F_GETRYXM(A.YSID) AS 医生,
    B.XM AS 姓名,
    F_GETSJZD(B.XBID) AS 性别,
    b.nl || (select neirong
    from shujuzidianmx
    where id = b.nldwid) as 年龄,
    B.CSRQ 出生日期,
    FB.NEIRONG 费别,
    A.MZH 门诊号,
    S.MC AS 号类,
    B.ZHENGJIANHAO 身份证号码,
    P.SXH AS 序号,
    PD.FLAG AS 是否叫号,
    PD.ID AS 叫号排队ID,
    NVL(PD.JLXZ, 1) AS 排队类型,
    SUBSTR(A.GHSJ, 1, 16) AS 挂号时间,
    B.YBH AS 医保号,
    pd.sjsxh as 实际顺序号,
    SUBSTR(A.GHSJ, 1, 10) AS 排序时间
    FROM YLGL_GHD A,
    BRXX B,
    YLGL_GHPD P,
    YLGL_SFXMJBXX S,
    SHUJUZIDIANMX FB,
    SHUJUZIDIANMX HL,
    PD_MZGHPD PD
    WHERE A.BRID = B.ID
    AND A.ID = P.GHDID
    AND A.FBID = FB.ID(+)
    AND A.HAOLEIID = HL.ID
    AND A.GHLX = S.ID(+)
    AND A.MZH = PD.MZH(+)
    AND A.KSID = 84
    AND A.GQSJ >
    TO_CHAR(SYSDATE, ‘YYYY-MM-DD HH24:MI:SS’)
    AND (A.YSID = 1125 OR NVL(A.YSID, 0) = 0)
    AND ((A.DJZT IN (3) AND PD.FLAG IN (0, 1)) OR
    (A.DJZT IN (0, 1) AND PD.FLAG IN (0, 1) AND
    PD.JLXZ IN (2, 3)))
    AND EXISTS (SELECT 1
    FROM PD_MZGHPD PD
    WHERE PD.MZH = A.MZH
    AND PD.ZSID IN (102))
    ORDER BY PD.FLAG,
    DECODE(PD.JLXZ, 2, 0, 1),
    DECODE(HL.NEIRONG, ‘急诊’, 0, 1),
    PD.SJSXH) M) n
    where n.group_idx = 1)
    WHERE ROWNUM <= 40000;

    二、注释掉除时间之外的其他影响查询结果集的条件，发现执行速度较快。
    三、逐步放开注释掉的条件，发现放开 AND a.ksid=84后执行速度最慢，初步定位此条件引起。查看其执行计划发现此条件走了索引。
    四、修改 AND a.ksid=108 89 等其他科室ID，执行速度也很快，猜测可能是统计信息过旧导致。
    五、重新收集统计信息
    EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname => ‘GDHIS’,tabname => ‘YLGL_GHD ‘,estimate_percent => 100,method_opt => ‘for all columns size auto’, degree => 8, cascade=>TRUE );
    统计信息收集完成后，问题依旧。
    专业DBA处理过程
    一、
    二、登录数据库
    三、通过 set autotrace on 去查看执行计划及统计，如果select 语句返回结果较多，应使用set autotrace traceonly
    输入sql语句执行，但是返回比较乱。必须用sqlplus去分析的原因，dba讲plsql显示的执行计划有可能不是实际的执行计划，在 sqlplus中最贴合实际的执行计划