- 如果没有优化过几千几万个SQL,哪里能练出火眼金睛,注意看跑得慢的SQL是HASH JOIN,跑得快的SQL是 HASH JOIN RIGHT SEMI
- 也就是说跑得慢的SQL是 HASH JOIN(inner join),跑得快的 SQL 是 HASH SEMI JOIN (semi join)
- 说人话就是跑得慢的SQL变成内连接了,跑得快的SQL是半连接(in/exists)。
- 明明SQL是半连接啊,咋变成内连接了呢,这涉及到优化器内部原理和大学课程里面的关系代数了这里就不装逼了,免得到时候一个个看不懂来问我烦死了。
- 问题又来了,就几万跟十几万的进行HASH JOIN 应该很快啊,如果跑的慢那只有一个解释,2个表的关联列数据分布都非常不均衡
- with t1 as
- (select /*+ materialize */
- a.user_name, a.invest_id
- from base_data_login_info@agent a
- where a.str_day <= '20160304' and a.str_day >= '20160301'
- and a.channel_id in (select channel_rlat from tb_user_channel a, tb_channel_info b where a.channel_id = b.channel_id and a.user_id = 5002)
- and a.platform = a.platform)
- select count(distinct user_name) ,count(distinct invest_id) from t1;
- Plan hash value: 901326807
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/8568259/viewspace-2102448/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/8568259/viewspace-2102448/