暂无图片
暂无图片
9
暂无图片
暂无图片
5
暂无图片

同一条SQL开发环境比生产环境执行速度快案例分享

原创 董小姐 2025-03-20
134

问题背景

核心应用在业务高峰期崩溃,开发反馈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、开发暂未回复

最后

不管是和开发、领导、现场沟通的时候一定要思路清晰,客观听取他们的分析,最终根据自己的知识积累和经验把控 来定位给与开发分析结果,不要思路被牵着走也不要急于向开发表达自己的看法。

「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论

筱悦星辰
暂无图片
4天前
评论
暂无图片 0
换位思考,不仅是一份己所不欲、勿施于人的体贴,更是一份将心比心、以心换心的善良。乐见别人好,也是乐见自己好;成全别人,往往也能成就自己。
4天前
暂无图片 点赞
评论
淡定
暂无图片
5天前
评论
暂无图片 0
同一条SQL开发环境比生产环境执行速度快案例分享
5天前
暂无图片 点赞
评论
芃芃
暂无图片
8天前
评论
暂无图片 0
同一条SQL开发环境比生产环境执行速度快案例分享
8天前
暂无图片 点赞
评论
广州_老虎刘
暂无图片
9天前
评论
暂无图片 0
等结果
9天前
暂无图片 点赞
1
老钢炮
暂无图片
1天前
回复
暂无图片 0
+1,老虎老师
1天前
暂无图片 点赞
回复