问题背景
核心应用在业务高峰期崩溃，开发反馈SQL执行时间长导致，让进行排查，SQL如下：
SELECT ID,OPERATE_USER_ID,JOB_ID,ROLE_ID,STATE,CHECK_DATA,ROW_STATE,UPDATE_TIME,CREATE_USER_ID,UPDATE_USER_ID,DELETED,CREATE_TIME,DESCRIPTION FROM AAF_JOB_ROLE
WHERE DELETED='0'
AND (ROW_STATE = '01');同样的SQL在单位开发环境查询输出时间是1ms，开发想不通同一条SQL为啥在配置比单位高的生产服务器上执行时间比单位服务器长，让排查原因。
分析过程
查该表记录数
发现where条件后面的条件输出结果和不加where条件输出结果一样，所以放弃给where条件的列创建索引，没意义。
select count(*) from AAF_JOB_ROLE; 返回137294 行记录
select count(*) from AAF_JOB_ROLE WHERE DELETED='0' AND (ROW_STATE = '01'); 返回137294 行记录查看表结构
该表无大字段，就是一普通表，无索引，因为表中DELETED列的值都是0，ROW_STATE列的值都是01，where后面的条件相当于全表查询。
统计信息是否过旧
select owner, table_name , object_type, stale_stats, last_analyzed
from dba_tab_statistics
where owner = 'PORTAL'
and table_name in( 'AAF_JOB_ROLE');
OWNER TABLE_NAME OBJECT_TYPE STA LAST_ANAL
------------------------------ -------------------- ------------ --- ---------
PORTAL AAF_JOB_ROLE TABLE NO 2025-3-11 下午10:04:17
说明：
stale_stats：NO未过期 YES 过期
补充：如果统计信息过期，重新收集统计信息
--查询找出统计信息过期的原因
select table_owner, table_name, inserts, updates, deletes, timestamp
from all_tab_modifications
where table_owner = 'PORTAL'
and table_name = 'AAF_JOB_ROLE';统计信息没过期是2025-3-11 下午10:04:17 ，但是于2025-3-17下午9:54:29进行过插入和删除操作
进行统计信息收集后在数据库连接工具中查询依然最短15秒输出结果最长1分20秒输出结果
--重新收集表的统计信息
BEGIN
DBMS_STATS.GATHER_TABLE_STATS(ownname => 'PORTAL',
tabname => 'AAF_JOB_ROLE',
estimate_percent => 100,
method_opt => 'for columns owner size auto',
no_invalidate => FALSE,
degree => 1,
cascade => TRUE);
END;
/
说明：
method_opt => 'for all columns size auto' 表示对出现在 where 条件中的列自动判断是否收集直方图
no_invalidate 不失效 = false 不失效 =失效 你要拿这个一用，很繁忙的系统立马硬解析飙升，业务就要找你了
半夜的时候可以设为false
ANALYZE TABLE T1 COMPUTE STATISTICS;执行时间查询
服务器上查询执行时间
set timing on
set autotrace traceonly
SELECT ID,OPERATE_USER_ID,JOB_ID,ROLE_ID,STATE,CHECK_DATA,ROW_STATE,UPDATE_TIME,CREATE_USER_ID,UPDATE_USER_ID,DELETED,CREATE_TIME,DESCRIPTION FROM AAF_JOB_ROLE
WHERE DELETED='0'
AND (ROW_STATE = '01');
现场数据库连接工具查询执行时间
现场数据库连接工具查询执行时间是1分35秒，很慢
结论
1、按照开发提供的重建表数据库连接工具查询执行时间依然没有改善，避免高水位导致查询时间长
2、建议开发在应用日志中是否能加个调取该sql的获取时长
3、回馈开发：明天上午高峰期比如10点，我再在数据库服务器上监控下该SQL的执行时长。当前该SQL在数据库服务器上执行时长1.17秒，不慢；通过数据库连接工具执行该SQL时长15秒不代表数据库服务器上执行该SQL慢。
4、回馈领导：领导反馈说现场的应用服务器和数据库服务器是在一个ip段的，不存在网闸，网络是不会存在瓶颈的
5、开发回复： 意思是怀疑数据库客户端到数据库服务器的网络有延迟？是这样的话应用没必要加日志，直接测试数据库客户端的电脑和应用服务器到数据库服务器间网络情况就可以，没那么麻烦
7、回复开发： 网络延迟不会只影响单条SQL 的执行时间的，即使存在网络延迟也是会影响应用整体慢
8、现场分别在上午高峰期9:00-11:30和下午高峰期2:30-4:30监控服务器磁盘IO、CPU负载、数据库会话均不高，SQL执行时间也都1秒15秒上下
9、开发暂未回复
最后
不管是和开发、领导、现场沟通的时候一定要思路清晰，客观听取他们的分析，最终根据自己的知识积累和经验把控 来定位给与开发分析结果，不要思路被牵着走也不要急于向开发表达自己的看法。
