接着聊下报表，下面仅为一家之言，你可以当成瞎扯淡，从我写了2，3天的报表sql来看，我发现，(我)在工作中：
（一)报表大部分是是3-4个表关联，2个表关联起来查询的很少，单表查询的更少，所以，每次看到别人在博客了说报表sql查询**数据花了0.0*秒，我就发现别人大部分是单表查询，再加上索引，查询条件使用索引，速度要多快有多快。
而我遇到的情况是，3-4个表一关联，在数据少的情况下，(单表最多6-7万)，速度很快，表的记录一多，速度直线下降，什么，加上索引，真实情况是，(1)表不是你建的，人家建表的时候为方便使用已经建了几个索引，你还想建索引，问DBA同不同意。
(2)你以为建了索引就很快，你建了索引，你能用得上吗？如果说建了索引就是方便用的，你建了索引，用户知道吗？你以为用户选择条件会知道那个条件是索引？我遇到过的情况是，为了加快查询速度，我在前台限制了用户必须选我的索引条件，结果就是用户不买账，凭什么要限制，我是管理员，我就是要看所有的下属门店，你限制了，我就得一个个点，漏了怎么办？就算不漏，这么多下属门店，什么时候才能点完，一句话，系统不好用，改。
(3)用户一般会偷懒，比如报表有很多条件可以选择，你千辛万苦说服人家千万要选择这个条件才能查询得更快，但是结果就是，用户选择的最多的就是只选择一个时间，然后直接点查询，然后，你哭了，索引建了这么多，单凭一个时间来过滤根本快不了多少。
(4)最怕的就是那种就算用户选了几个条件也走不了索引的，这种情况就是表索引建太多了，不能再建索引了，而要查询的偏偏要按那个没有索引的字段来过滤，这种情况很头疼。
(二)刚说了报表很少有单表查询的，单表查询要什么报表，直接多写几行代码不就得了。再来说说用户，俗话说顾客是上帝，上帝有什么需求你就得做。工作中由于一个组织下面的下属门店太多，直接使用select标签根本放不下，所以使用了那种既可以下拉选择，也可以输入关键字过滤的控件，好像叫combox，名字忘记了。一开始，用户更不不会用，教了很多次才教会用户怎么使用关键字过滤，然后用户又有意见了：(1)选择框太慢，这是因为下属组织太多，(2)输入关键字太麻烦，下属组织几十个，我就要输入几十次，麻烦，遇到这种情况，直接跪了，如张三和李四同属于大BOSS。大BOSS下面有很多小弟。张三管一部分小弟，李四管一部分小弟。小弟之间没有任何关系，这时候没有办法区分那些小弟是归张三管的，那些小弟归李四管。
(三)上面的需求说什么也做不了，那退而求其次，品牌下面的机型不也是可以输入可以选择吗。我要求把常用的几个品牌，品牌下面常用的几个机型放在最前面，方便使用，你以为简单的使用order by 品牌名字 desc 就可以搞定吗？错，品牌之间不是按常用来插入的，说不定最常用的在最后面呢。这时候得这样写了：
--按品牌热度排序 select * from t_brand order by decode(brand_name,'苹果',6,'三星',5,'天语',4,'海信',3,'华为',2,'小米',1,1/brand_id) desc
或者采用配置表：
with tmp_t(brand_name,pr) as( select '苹果',6 from dual union all select '三星',5 from dual union all select '天语',4 from dual union all select '海信',3 from dual union all select '华为',2 from dual union all select '小米',1 from dual ) select pb.* from t_brand pb,tmp_t t order by decode(pb.brand_name,t.brand_name,t.pr,1/pb.brand_id) desc
什么？系统框架不支持这种写法，那你用jdbc写吧，不就多写几行代码吗？
(四)人家的报表都是0.0*秒就查询到记录，最慢的也就3-4秒，我的报表多少秒超时呢？说出来忏愧，报表超时时间120秒，你没听错，就是120秒，用户提出什么要求，一句话，做，前提是你得多等几分钟，几分钟小事，只要满足我的需求就行。(一般都是一分钟内查询出来的，太慢了的化会定时沉淀数据。)，几十秒都是小事，工作中遇到上传Excel解析到数据库的，等上10分钟才出结果很正常。工作中数据校验很少是单表的，都是先查询这个表看是否满足条件，满足继续换一个表校验，一轮下来，校验4，5个表很正常。
不写了。
全文完。