大数据表之间join 的优化
我最近在做个查询报表，查询速度特别慢，大致是 select * from a join b on b.c1=a.c1 join c on c.c2=b.c2
where （筛选a）
表a特别大，有2KW条记录。
我们经理认为建立临时表把筛选a的记录存放到临时表中，再让临时表来join 表b和表c。
可我认为这样和3个表直接join再where效率是一样的？
另外我认为关键还是执行以下查询时三个表要有合适的索引seek，我想在表a上新建索引以证明我的观点，可这个表实在太大，不敢贸然建立。
select * from a join b on b.c1=a.c1 join c on c.c2=b.c2
where （筛选a）
请高手们评点下我的想法对不对：先筛选大表a插入到临时表，再用临时表join 表 b和表c根本就没有效率上的优势呢？

------解决方案--------------------
a上面建立些索引吧 没有看到你的筛选条件，所以不知道在那个列上合适

用临时表 快不到那里的。
------解决方案--------------------
如果使用临时表 

insert into #t select ...from tb where ....
的前提是红色的这一段查询会很快，要不就没必要了。。。。

如果很快，但是#t里面的数据很多 那么可以在#t 上面建立的索引

然后在join
------解决方案--------------------
当然是大表中再提取部分数形成小的临时表再join快
------解决方案--------------------
加WHERE 条件筛选后A 多大？ 为嘛一定要所有列？？？？

关联条件需要有索引
------解决方案--------------------
关键是b\c表的数据量以及a与b\c表的对应关系

如果b\c表的数据量不大，而且a与b\c表的对应关系是1对1或者多对1，临时表方法基本无效
如果b\c表的数据量大，或者a与b\c表的对应关系是1对多，临时表方法可能无效，关键看在a表的筛选条件

在大表(a)建立合适的索引永远是优化的第一步，这部分没做好，说其他的都是舍本逐末



------解决方案--------------------
对，关键看你最大的那块的数据是咋个优化的。关键要用到索引。
------解决方案--------------------
看从2000万筛选出来的数据有多大..如果筛选出来1500万那完全可以按你像的来...你可以count(1) 一下.where条件不变..看看筛选多少条..如果条数很少..而且筛选的很快的话..感觉还是你老大的办法可行! 大不了给临时表创建索引! 或是 数据量小hash join也应该挺快!