在业务中涉及到汇总各项数据，图表数据展示等功能的时候，自然缺少不了report。由于报表库，表的字段长度，数据量都是目前业务中最大的一个模块，所以慢sql的优化是需要一直要去做的，并且在实践中总结经验和教训，尽可能的提出最优方案。
Attention：
报表出现过一个字段长度过长而无法增加某一字段varchar（5000）；
原因：因为在MySQL表设计中，所有字符类型的长度加起来不能超过65535，可以考虑使用blob或者text类型。
====================================================================================================
慢sql案例：
1.只针对报表来说，报表可以采取，前一天晚上提前统计好客户（user）所需要的数据，比如顾客的常规性查询
1 select column1，column2，column3~ from table_name where user_id =xxx and ~ and ~ limit 100000,500
2 Attention：由于报表的表字段经常达到上百个，只需要将所需要的列名select即可，不推荐使用select * ，而且在维护管理MySQL过程中尽量避免select *。
原因：
这种类型的sql主要是耗时在分页上，并且将前面查询过的数据抛弃掉。可以根据慢日志发现，这些sql是从limit 0,500开始查询的，也就是说每一次都只取500条。这个是客户的报表导出功能，最终会将这些数据导出成excel
解决方案：
可以在前一天晚上，将每个租户的每个店铺或者其他级别group by 来将这些数据全部导出到hadoop里面或者直接导出成excel；可以是drds 中trade_daily_report的格式，包括各种汇总信息。
2.统计报表的批量并发性sql，第一列数字表示该类型的sql在同一时刻，通过慢sql页面抓取到的（由于开发反馈insert或者replace时，数据库很慢）
1 206 replace into table_report1~~(这些都是一条sql，value一组数据) 2 215 replace into table_report2~~ 3 1737 replace into table_report3~~ 4 79 replace into table_report4~~
原因：
这种类型的慢sql主要是在commit的时间消耗比较多。（从开发的角度来思考，由于双十一的数据量过大，不能从降低并发的角度优化，否则数据无法完成。而且程序端出现诸多的插入超时，超时时间为10s）
解决方案：
优化策略是将多组value值一次性replace，这样就可以减少commit的次数，但是也要注意value的数据条数不要过大，最好根据数据库的性能实际测试一下；另外若数据量过大的情况，可以尽量增加程序端的超时时间。