大数据表之间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也应该挺快!
