SQL有外连接的时候注意过滤条件位置否则会导致网页慢
2013-05-03 00:00
513 查看
奶奶的,为啥现在五一节只放3天,5月的天气最适合出游了,不过俺们这些苦逼的IT男是没法享受了。
一来到公司,项目经理就找到开发leader,说我们网站 页面很慢,让他排查原因。
一听说 网站慢,页面慢哥就来精神了,哥的老本行就是 解决“慢”的问题。
开发leader 很郁闷的说,我们已经加了 memcache了,20分钟 cache一次,咋个还是慢呢,
于是哥就问,那个网页跑了哪些SQL? 能抓出来让我看看吗? 开发Leader 果断的把SQL 抓了出来。
经过排查,我们发现了一个SQL确实跑得慢。该SQL 如下
执行计划如下
大家能发现这个SQL 的问题吗? 这个 SQL 之所以跑得慢是因为开发人员把SQL的条件写错位置了
正确的写法应该是 下面这样的
执行计划如下
之前SQL要跑至少5秒以上,现在0.1秒能出结果。
各位童鞋,SQL 有外连接的时候,要注意过滤条件的位置,记住啦!!!
有SQL 需要优化的 欢迎加入 QQ 群 220761024 申请注明 来自CSDN
一来到公司,项目经理就找到开发leader,说我们网站 页面很慢,让他排查原因。
一听说 网站慢,页面慢哥就来精神了,哥的老本行就是 解决“慢”的问题。
开发leader 很郁闷的说,我们已经加了 memcache了,20分钟 cache一次,咋个还是慢呢,
于是哥就问,那个网页跑了哪些SQL? 能抓出来让我看看吗? 开发Leader 果断的把SQL 抓了出来。
经过排查,我们发现了一个SQL确实跑得慢。该SQL 如下
select * from (select u.NAME UniversityName, u.id UniversityId, count(a.SIGNUPNUMBER) playercnt from T_B_UNIVERSITY u left join T_D_EDUCATION e on e.UNIVERSITY_ID = u.id left join T_D_VIDEO_PLAYER a on a.USER_ID = e.user_id and e.ISDEFAULT = 1 and e.ISVALID = 1 and a.AUDITSTATUS = 1 and a.ISVALID = 1 left join T_D_USER c on a.USER_ID = c.id and c.ISVALID = 1 where u.REGION_CODE like '43%' group by u.NAME, u.id) order by playercnt desc;
执行计划如下
执行计划 ---------------------------------------------------------- Plan hash value: 3938743742 -------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 142 | 10366 | 170 (3)| 00:00:03 | | 1 | SORT ORDER BY | | 142 | 10366 | 170 (3)| 00:00:03 | | 2 | HASH GROUP BY | | 142 | 10366 | 170 (3)| 00:00:03 | |* 3 | HASH JOIN RIGHT OUTER| | 672 | 49056 | 168 (2)| 00:00:03 | |* 4 | TABLE ACCESS FULL | T_D_USER | 690 | 5520 | 5 (0)| 00:00:01 | | 5 | NESTED LOOPS OUTER | | 672 | 43680 | 162 (1)| 00:00:02 | |* 6 | HASH JOIN OUTER | | 672 | 37632 | 14 (8)| 00:00:01 | |* 7 | TABLE ACCESS FULL | T_B_UNIVERSITY | 50 | 2050 | 8 (0)| 00:00:01 | | 8 | TABLE ACCESS FULL | T_D_EDUCATION | 672 | 10080 | 5 (0)| 00:00:01 | | 9 | VIEW | | 1 | 9 | 0 (0)| 00:00:01 | |* 10 | FILTER | | | | | | |* 11 | TABLE ACCESS FULL| T_D_VIDEO_PLAYER | 1 | 15 | 3 (0)| 00:00:01 | -------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 3 - access("A"."USER_ID"="C"."ID"(+)) 4 - filter("C"."ISVALID"(+)=1) 6 - access("E"."UNIVERSITY_ID"(+)="U"."ID") 7 - filter("U"."REGION_CODE" LIKE '43%') 10 - filter("E"."ISVALID"=1 AND "E"."ISDEFAULT"=1) 11 - filter("A"."USER_ID"="E"."USER_ID" AND "A"."AUDITSTATUS"=1 AND "A"."ISVALID"=1)
大家能发现这个SQL 的问题吗? 这个 SQL 之所以跑得慢是因为开发人员把SQL的条件写错位置了
正确的写法应该是 下面这样的
select * from (select u.NAME UniversityName, u.id UniversityId, count(a.SIGNUPNUMBER) playercnt from T_B_UNIVERSITY u left join T_D_EDUCATION e on e.UNIVERSITY_ID = u.id and e.ISDEFAULT = 1 and e.ISVALID = 1 left join T_D_VIDEO_PLAYER a on a.USER_ID = e.user_id and a.AUDITSTATUS = 1 and a.ISVALID = 1 left join T_D_USER c on a.USER_ID = c.id and c.ISVALID = 1 where u.REGION_CODE like '43%' group by u.NAME, u.id) order by playercnt desc;
执行计划如下
执行计划 ---------------------------------------------------------- Plan hash value: 2738827747 --------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 142 | 11218 | 25 (16)| 00:00:01 | | 1 | SORT ORDER BY | | 142 | 11218 | 25 (16)| 00:00:01 | | 2 | HASH GROUP BY | | 142 | 11218 | 25 (16)| 00:00:01 | |* 3 | HASH JOIN RIGHT OUTER | | 301 | 23779 | 23 (9)| 00:00:01 | |* 4 | TABLE ACCESS FULL | T_D_USER | 690 | 5520 | 5 (0)| 00:00:01 | |* 5 | HASH JOIN RIGHT OUTER| | 301 | 21371 | 17 (6)| 00:00:01 | |* 6 | TABLE ACCESS FULL | T_D_VIDEO_PLAYER | 78 | 1170 | 3 (0)| 00:00:01 | |* 7 | HASH JOIN OUTER | | 301 | 16856 | 14 (8)| 00:00:01 | |* 8 | TABLE ACCESS FULL | T_B_UNIVERSITY | 50 | 2050 | 8 (0)| 00:00:01 | |* 9 | TABLE ACCESS FULL | T_D_EDUCATION | 301 | 4515 | 5 (0)| 00:00:01 | --------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 3 - access("A"."USER_ID"="C"."ID"(+)) 4 - filter("C"."ISVALID"(+)=1) 5 - access("A"."USER_ID"(+)="E"."USER_ID") 6 - filter("A"."AUDITSTATUS"(+)=1 AND "A"."ISVALID"(+)=1) 7 - access("E"."UNIVERSITY_ID"(+)="U"."ID") 8 - filter("U"."REGION_CODE" LIKE '43%') 9 - filter("E"."ISDEFAULT"(+)=1 AND "E"."ISVALID"(+)=1)
之前SQL要跑至少5秒以上,现在0.1秒能出结果。
各位童鞋,SQL 有外连接的时候,要注意过滤条件的位置,记住啦!!!
有SQL 需要优化的 欢迎加入 QQ 群 220761024 申请注明 来自CSDN
相关文章推荐
- SQL有外连接的时候注意过滤条件位置否则会导致网页慢
- SQL有外连接的时候注意过滤条件位置
- SQL有外连接的时候注意过滤条件位置
- SQL有外连接的时候注意过滤条件位置
- SQL优化经典案例----外连接where条件位置优化
- Oracle SQL查询,日期过滤条件要注意的一点
- 写sql语句连接的时候注意的一个小细节
- [转]sql 左右连接 on 条件注意事项
- SQL优化经典案例----外连接where条件位置优化
- sql中外连接条件位置不同导致的查询结果不过
- 关于SQL语句外连接中的过滤条件
- Linq中jion方法连接集合对象时候,多条件处理
- 外连接 ON 条件的三个作用 SQL中on条件与where条件的区别
- 免安装Oracle客户端使用PL/SQL连接Linux Oracle 注意事项
- 使用mysql长连接的时候要注意
- T-SQL查询——非聚集索引的覆盖,连接,交叉和过滤
- SQL优化之针对count、表的连接顺序、条件顺序、in及exist的优化
- C_连接Access、SQL_Server、Oracle、MySQL、DB2和SyBase六种不同数据库的程序源码和需要注意的点
- Template写mysql时注意,空的和null型的不要插入数据,否则查出来可能会不否和条件
- SQL查询优化,注意where条件的顺序