SQL有外连接的时候注意过滤条件位置
2013-05-02 10:48
274 查看
2013年/5月/2日
奶奶的,为啥现在五一节只放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
奶奶的,为啥现在五一节只放3天,5月的天气最适合出游了,不过俺们这些苦逼的IT男是没法享受了。
一来到公司,项目经理就找到开发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中外连接条件位置不同导致的查询结果不过
- SQL优化经典案例----外连接where条件位置优化
- 关于SQL语句外连接中的过滤条件
- [转]sql 左右连接 on 条件注意事项
- SQL优化经典案例----外连接where条件位置优化
- 写sql语句连接的时候注意的一个小细节
- Oracle SQL查询,日期过滤条件要注意的一点
- sql多变量条件查询,变量条件可能为全部都符合。利用1=1做字符串连接查询
- 多条件组合查询,sql语句连接
- django model filter 条件过滤,及多表连接查询、反向查询,某字段的distinct
- queryDataSet中多条件过滤数据集的sql写法
- Asp.net2.0连接SqlServer200的时候需要注意的问题
- sqlserver中分组查询,条件过滤,排序,写这个sql,我为自己感到骄傲
- T-SQL查询——非聚集索引的覆盖,连接,交叉和过滤
- Mysql 左连接查询条件位置不同造成数据查不出来
- 注意sqlplus环境中的连接符号“-”