报表需求1：从六千多万条数据中找需要的top100
方法：1.mysql explain 2.索引
由于数据量大，因此我们需要通过索引的方式降低搜索时间，不加索引FineReport直接报了sql时间过长的错误。
因此在对应的月份、用户等字段加了联合索引（保证这些选取的字段不为空，联合索引有最左匹配的说法，空了就全表搜了）
加完索引时间从没法搜降到了五秒左右。
报表需求2：从六千多万条数据*n月中找sum、avg等最大的top100
sum、avg通过索引也可以降低执行时间。个人想法是通过地区表通过exist的方式计算哪些可选项，但是。。。可能还是比较麻烦，那就算了
同事：几千万条，从sql入手还是太慢了，想别的办法
待续。。。
报表需求三：几个筛选项不要筛出空的结果
通常方法：distinct，其原理为sort+逐行迭代排序，所以输出有序，但会全文件排序。由于数据量过大，慢的一批
解决方法：1.group by，依然慢的一批。
2.索引+exists (select prov_name from dim_area where prov_name='xxx')极快，因此通过附加的地区表与子查询查到哪些地区有数据，把这些作为结果。
总结：不要用会导致全表查的操作，建议通过select+索引的奇怪操作来做（走索引 走索引 走索引！）。
mysql explain
https://www.cnblogs.com/tufujie/p/9413852.html
explain出来的信息有10列，分别是id、select_type、table、type(对表访问类型)、possible_keys(可能使用的索引)、key(实际索引)、key_len、ref、rows(扫描出的行数，估算的行数)、Extra
mysql 联合索引
多个字段同时建立的索引(有顺序，ABC，ACB是完全不同的两种联合索引)（abc就是建a/ab/abc三个索引）
1.最左匹配
如abc，先匹配a，再bc，如果直接bc会不使用索引
2.最常用、筛选数据最多的字段放前边
mysql 索引btree hash
hash索引一次就能定位，btree需要从根节点到叶子节点，最后才到具体页
所以hash快，但是其缺点是：1.不支持范围查询(between)，只支持（=、in、<=>）
2.btree可排序，hash不可以
3.hash组合索引，通过所有的加一块，才算hash，所以只拿前几个进行搜索，不走索引
4.当遇见大量Hash值相等的情况，hash不一定比btree快
mysql 索引 <=>、in、not in
小数据量不走索引，大的走，所以还是通过explain看比较好