（4）记录大概时间，然后去查看报告打开对应报表。报表加载完成后，下载日志到本地分析
（5）通过Notepad++打开bi.log
A.搜索“Create dashboard”，并对照之前记录的时间以及咱们打开的报表的名称，找到咱们这次打开报表对应的唯一ID。比如我这里的报表名是：“coffee_test”，唯一ID是“coffee_test20210130173614-693”
B.搜索“first page area”找到这次报表打开花的时间。比如这里的215516ms=215s=3.6min
C.然后搜索步骤A中找到的唯一ID：“coffee_test20210130173614-693”，从搜索结果中找到花时间最长的查询。
后面紧跟的sql就是执行慢的sql,花了214990ms=3.58min，这个时间跟报表打开时间进行对比，可以确认这个报表就是慢在这里，实际报表中可以不只是一个地方慢，凡是时间比较长的都需要看看。
sql:
SELECT `交易时间`, `产品名称`, COUNT(DISTINCT `利润`) AS LONG_COL_0, COUNT(DISTINCT `区域代码`) AS LONG_COL_1, COUNT(DISTINCT `市场开销`) AS LONG_COL_2
, COUNT(DISTINCT `总成本`) AS LONG_COL_3, COUNT(DISTINCT `订单ID`) AS LONG_COL_4, COUNT(DISTINCT `边际利润`) AS LONG_COL_5, COUNT(DISTINCT `销售额`) AS LONG_COL_6
FROM coffee_test
GROUP BY `交易时间`, `产品名称`
ORDER BY `交易时间` ASC, `产品名称` ASC
LIMIT 5000000
D.在数据库执行一下这个sql看看花费时长。这里的时长不一定跟日志中记录的完全一样，但是应该可以明显的看出来数据库执行sql慢。
2.对于上述这种数据库执行sql慢导致的报表打开慢的问题，可以尝试的解决方式如下：
（1）如果有购买集市这个模块，且数据对实时性要求不是太高，可以考虑将数据集入集市。入集市后查看报告就不再走数据库实时查询，而是走集市查询，集市采取列存储，有加速的作用。
比如咱们之前的报告，入集市后查询速度提升很多。
2021-02-02 17:19:42.416 |-admin-4adaec56b4e04134a67c6ef563fb25de |-[INFO] |-g5.db.RTDashboard.checkPendings(RTDashboard.java:740) | Open db coffee_test20210202171941-1491 first page area cost 749
备注：入集市后理论上有优化，优化的情况要看实际情况，不是一个固定的。
（2）如果报告上针对全局进行的过滤，可以考虑将过滤放到sql数据集的sql中进行，另外对数据库进行优化也是必须的，效果更佳明显
参考：https://yonghongtechonline.udesk.cn/question/226409
