union all查询慢，优化办法

先简单介绍一下我的项目。
是一个购销存系统（这不重要）
由于数据量太大，所以每天都分一张表，一张表的数据量大概在18W样子，双十一这种节日能到60W数据样子一天。
其中要计算期初的语句

下面还有很多很多，语句很长。每次查一年的期初都要花很久，而且要求一次都查出来，数据量很大。
就是从一张表筛选出数据，然后疯狂union all，这就导致了查询的时间边长。
我的解决办法是，如果你的union all很多的话，可以做成视图，相当于把所有的表数据合成一张表来显示。
但数据实际上还是分表存的，只是展示出来的结果让你看上去是一张表。相当于把union all这一层给提前做好了。这样查询的时候就只要控制某个字段是时间，比如date>'2019-03-05’这样子。
但是也有弊端，视图在查数据量较小的时候反而会慢很多，因为你查之前，需要时间把视图预编译，这个开销是很大的。所以这只适合在查数据量很大的时候。我是用视图把150秒的语句优化到了100秒。比如原本20秒的语句，我用视图查可能要查30秒。所以也要看情况用。存储过程我就不贴出来了，有兴趣的可以私，看到会及时回复。
另外我的语句也不够好，其实每次查询的时候group by也很费时间，建议在最外层写group by，把里边的group by都去掉。另外，尽量少用连表查询。比如我每条查询语句中都连了一张shop表，主要是去shop表里取表名，这其实很不合理，我后来才意识到这一点。取表名可以用java代码做匹配，这样会很快。sql只用来取数据，需要连表查的能用java代码做匹配就用代码匹配。连表带来的开销会很大，会得不偿失。sql最快的情况是只用来做select，函数尽量少用，尤其是转换大小写的函数，千万避免。数据量小的时候你看不出差别，数据量一大，这个函数会特别耗时间。在mysql数据库中表现得特别明显。sqlserver中倒是没那么大的差异。但还是尽量在数据库里少用这种数据库函数。