抚州北京网站建设,制作网站电话,wordpress制作数据可视化,网站推广都有哪些目录 场景#xff1a;
环境#xff1a;
慢SQL查询一#xff1a;
问题一#xff1a;办件列表查询慢
分析#xff1a;
解决方法#xff1a;
问题二#xff1a;系统性卡顿
分析#xff1a; 解决方法#xff1a;
慢SQL查询二 扩展#xff1a; 场景#xff1a; 线…目录 场景
环境
慢SQL查询一
问题一办件列表查询慢
分析
解决方法
问题二系统性卡顿
分析 解决方法
慢SQL查询二 扩展 场景 线上环境出现办件列表查询非常慢大概要1分钟才刷出来及很多功能都出现系统性卡顿。 环境 oracle数据库工作表历史表act_hi_proinst单表数据量一百多万 慢SQL查询一 select * from (select v.sql_id, v.sql_text, v.sql_fulltext, v.FIRST_LOAD_TIME, v.last_load_time, v.elapsed_time, v.cpu_time, v.disk_reads, v.EXECUTIONS, v.LOADS, v.cpu_time / v.executions / 1000 / 1000 ave_cpu_time, v.ELAPSED_TIME / v.executions / 1000 / 1000 ave_time from v$sql v) a where a.last_LOAD_TIME 2024-01-01/00:00:00 and ave_time 5 and a.executions 0 order by ave_time desc; 其中各字段含义如下 v.sql_text: 包含SQL语句的文本内容 v.sql_fulltext: 包含完整的SQL语句文本内容 v.FIRST_LOAD_TIME: SQL语句第一次加载到共享池中的时间 v.last_load_time: SQL语句最后一次加载到共享池中的时间 v.elapsed_time: SQL语句的总执行时间以微秒为单位 v.cpu_time: SQL语句的总CPU执行时间以微秒为单位 v.disk_reads: SQL语句的总磁盘读取次数 v.EXECUTIONS: SQL语句的总执行次数 v.LOADS: SQL语句的总加载次数 ave_cpu_time: 每次执行的平均CPU执行时间以秒为单位 ave_time: 每次执行的平均总执行时间以秒为单位 问题一办件列表查询慢
办件查询列表主要涉及到如下两个SQL语句 select * from (select a.*,rownum as num from (select RES.* ,H.NAME_ as bizName, H.XZQ_ as bizXzq, H.DUE_DATE_ as bizDueDate, H.PROC_DEF_KEY_ as bizProcDefKey, H.CATEGORY_ as bizCategory, H.DATUM_TYPE_ as bizDatumType, H.START_USER_ID_ as bizStartUserId, H.DEPT_CODE_ as bizDeptCode,H.F1_ as bizF1, H.F2_ as bizF2, H.F3_ as bizF3, H.F4_ as bizF4, H.F5_ as bizF5, H.F6_ as bizF6, H.F7_ as bizF7, H.F8_ as bizF8, H.F9_ as bizF9, H.F10_ as bizF10, H.F11_ as bizF11, H.F12_ as bizF12, H.F13_ as bizF13, H.F14_ as bizF14,H.F15_ as bizF15, H.F16_ as bizF16, H.F17_ as bizF17, H.F18_ as bizF18, H.F19_ as bizF19, H.F20_ as bizF20from gisqbpm.ACT_HI_PROCINST RESleft join gisqbpm.ACT_HI_BIZ_PROCINST H on H.PROC_INST_ID_ RES.PROC_INST_ID_)a where rownum15 )b where b.num0
线上测试1.58秒
select count(RES.ID_) from gisqbpm.ACT_HI_PROCINST RES, gisqbpm.ACT_HI_BIZ_PROCINST H where H.PROC_INST_ID_ RES.PROC_INST_ID_; 但是分页查询总数的sql语句执行五次5.932s3.78s2.89s, 2.5s1.9s
分析 原因是前端刚打开办件查询列表时由于查询总数的sql语句没有任何过滤条件导致两种表只有关联查询并没有过滤故全表扫描耗时较长。 解决方法 由于两张关联表中数据是一对一的因此如果仅仅考虑第一次查询慢的问题直接可以去掉关联单表查询的总数就可以了。 但是事与愿违这只能解决办件查询第一进入的问题如果有条件参数过滤的话关联表的参数还要加上这个关联表后端改动有点大。 因此建议线上前端处理办件查询第一次进入时带上时间范围。 问题二系统性卡顿
描述也不算是系统系卡顿吧有写接口还是比较快的只能说有很多重要的操作反应都很慢下面是获取的当天的慢SQL。 这里挑选了几个耗时较长的简单的分析这里面的sql是另外一个部门的 DECLARE job BINARY_INTEGER : :job; next_date DATE : :mydate; broken BOOLEAN : FALSE; BEGIN pro_inert_rybjlcx_sed; :mydate : next_date; IF broken THEN :b : 1; ELSE :b : 0; END IF; END; 1.该SQL执行Execution一次 加载LOADS一次 平均耗时将近一个小时。执行 pro_inert_rybjlcx_sed慢 SELECT COUNT(0) FROM (SELECT * FROM (select * from v_fwdyaq where 11) WHERE 11 ) 2..该SQL执行Execution11次 加载LOADS216次 平均每次执行耗时接近半个小时。需要对该语句重点优化 DECLARE job BINARY_INTEGER : :job; next_date DATE : :mydate; broken BOOLEAN : FALSE; BEGIN sms_ts; :mydate : next_date; IF broken THEN :b : 1; ELSE :b : 0; END IF; END; 3.该SQL执行Execution四次 加载LOADS2次 平均每次执行耗时25秒。加载较频繁需要重点优化行 sms_ts操作 SELECT COUNT(DISTINCT A2.QLBSM) FROM BDCDJ.DJFZ_CQZS A2,BDCDJ.QLR A1 WHERE A2.QLBSMA1.QLBSM AND A2.QSZT1 AND TRIM(A2.BDCQZH):1 AND A1.QLRMC LIKE :2 4.该SQL执行Execution317次 加载LOADS29次 平均每次执行耗时9秒。执行和加载较频繁需要重点优化行 select * from ( select a.*, ROWNUM rnum from ( select RES.*, H.NAME_ as bizName, H.XZQ_ as bizXzq, H.DUE_DATE_ as bizDueDate, H.PROC_DEF_KEY_ as bizProcDefKey, H.CATEGORY_ as bizCategory, H.DATUM_TYPE_ as bizDatumType, H.START_USER_ID_ as bizStartUserId, H.F1_ as bizF1, H.F2_ as bizF2, H.F3_ as bizF3,H.F4_ as bizF4, H.F5_ as bizF5, H.F6_ as bizF6, H.F7_ as bizF7, H.F8_ as bizF8, H.F9_ as bizF9, H.F10_ as bizF10, H.F11_ as bizF11, H.F12_ as bizF12, H.F13_ as bizF13, H.F14_ as bizF14, H.F15_ as bizF15, H.F16_ as bizF16, H.F17_ as bizF17, H.F18_ as bizF18, H.F19_ as bizF19, H.F20_ as bizF20 from ACT_HI_PROCINST RES left join ACT_HI_BIZ_PROCINST H on H.PROC_INST_ID_ RES.PROC_INST_ID_ WHERE (RES.DELETE_REASON_ :1 or RES.DELETE_REASON_ is null) order by RES.START_TIME_ desc ) a where ROWNUM :2) where rnum :3 分页查询语句执行了7680次平均每次执行10s,看SQL执行计划走了时间字段然而线上没有线上加上索引线上执行为0.1秒 分析 线上START_TIME_ 列没有走索引 解决方法
添加索引 慢SQL查询二 select * from (select v.sql_id, v.SQL_FULLTEXT, v.EXECUTIONS, v.ELAPSED_TIME / v.executions / 1000 / 1000 ave_time, v.parsing_user_id, last_LOAD_TIME from v$sql v) a where a.last_LOAD_TIME 2024-02-01/00:00:00 and ave_time 5 and a.executions 0 and a.parsing_user_id(SELECT user_id FROM all_users where usernameGISQBPM) order by ave_time desc; 扩展
1.loads 和execution的区别于联系 loads表示SQL语句在共享池中被加载的次数。每当一个SQL语句被解析并放入共享池中loads的值就会增加。这个值可以帮助您了解一个SQL语句被重复使用的频率。 executions表示SQL语句被执行的次数。每当一个SQL语句被实际执行executions的值就会增加。这个值可以帮助您了解一个SQL语句在实际执行过程中的频率。 2. 同一个SQL为什么会被重复加入到共享池 在Oracle数据库中同一个SQL语句可能会被重复加入到共享池的原因有以下几点 绑定变量不同如果SQL语句使用了绑定变量即在SQL语句中使用了占位符那么不同的绑定变量值会导致不同的SQL语句被加入到共享池中。 SQL语句文本不同即使SQL语句的逻辑相同但如果SQL语句的文本不同比如空格、大小写等Oracle也会将它们当作不同的SQL语句进行处理。 不同的解析环境在不同的解析环境下相同的SQL语句可能会被多次解析并加载到共享池中比如在不同的会话或者不同的数据库连接中。 共享池空间不足如果共享池空间不足Oracle可能会根据一些策略进行SQL语句的淘汰和重新加载这也会导致同一个SQL语句被重复加载到共享池中。
