报表sql心得一篇

最近很忙，有个项目马上要招标，一个项目等着工，若干琐碎的事进行中，有一段时间没更新些有营养的东西了
说个题外话先。
今天开机准备把昨天的东西debug一下，很习惯地右键项目的启动文件开始debug，机器突然蓝屏重启。开始以为又是内存在偷偷超频，检查了一下bios，发现没什么问题，也没怎么在意，隧重新开启vs2008继续debug。非常吃惊的发现debug程序的时候机器继续蓝屏，而且两次都是在debug刚启动，连浏览器都没打开的时候，这就有点意思了。
仔细回想一下刚才做的事情，比较引起我注意的是刚才点击了暴风影音的头条新闻看了一下，但是打开新闻的浏览器是ie（我的实际默认浏览器是360browser），会不会是这个地方造成debug启动默认浏览器错乱导致蓝屏？于是打开360browswer将其重新设置为默认ie浏览器，然后开始debug，问题解决。
这次教训告诉我们，出现问题后要仔细分析问题的周边因素，有时候一些细节问题导致的后果往往是很严重的，但是解决起来却很简单，重在发现。
----华丽的分割线----
进入正题。
这个星期光忙活做报表了，连着做了N个。做报表差不多快3年了，从reportservice2000，到2005，再到现在的2008（本人没有接触过crystal reports...），微软的报表工具是越来越牛X了，配合数据库的一些新特性和优化的性能，尽管报表趋于复杂化，但是等待时间还是在能够后接受的范围内，并且开发愈发灵活。
不过光靠工具和数据库本身是不够的，作为报表的灵魂----sql的性能直接决定报表的速度。总结一下报表sql的经验先：
1.确定你在sql引用到的表都是你需要的（很多人喜欢图方便，把之前成熟的sql直接拷贝来用，却没有根据当前需求的需要把不需要用到的表相关的sql去掉，平白增加的查询的复杂度）
2.确定使用jion去实现所有的表连接（事实证明inner jion是效率最高的，不过left join是使用的最频繁的，效率最烂的是笛卡尔积，除了一些特殊场合，笛卡尔积基本已经无视。文尾为会举一个用到笛卡尔积的例子，证明笛卡尔积还是个很优秀的算法思想）
3.如果在where中用到in (select xx from yy)类似的语法，要注意算法平衡：如果主对象很大而查询对象所在的表比较小时，这种做法相对效率较高（如果在查询的列上有index更好），如果主对象较小而查询对象所在表较大时，inner join是更好的选择
4.当一个结果集来自若干个表的运算时，如果有必要的话，可以先将较大的表计算出一个中间结果储存在表变量（本人比较喜欢表变量，事实上在单比查