小张是一家公司的财务经理，需要分析年末的财务报告，小张就开始对财务数据进行处理并制作报告。可是在查看报告时却发现，仅仅480W的明细数据，报告加载就用了1分钟左右才展示出来。心想，难道要让老板去查看这么慢的报告吗？

于是，他通过制作报告中的检测性能，排查到报表中有3个表达式是js表达式，没有下推到数据库执行导致报表性能很慢，最后他按照性能检测中的建议将这几个表达式改为了SQL表达式，再次打开报表时仅用时2秒。

报表性能检测原因分为三类，包括系统原因、报表原因和数据集原因。当报表中存在这三类原因中的任何一种时，报表右上角的“检测性能”上会出现小红点提醒，用户可以点击“检测性能”查看具体原因和建议，并可以点击“检测性能”中的“下载”将所有性能慢的原因以Excel格式导出，如下图所示：

报表性能检测频率可以通过系统设置->系统参数配置->基本参数配置中的 db.performance.test.interval 属性控制，如下图所示：

该值默认为60s，即每分钟对报表性能检测一次，用户也可以手动修改该值，修改后将按修改后的值进行检测。

比如用户在对维度列进行筛选时，产品默认显示的值是1万，超过1万的值不会再显示。一是我们认为一般情况下，维度值不会超过1万；二是对于过滤组件来说，产品有个功能是计算过滤组件之间的联动关系，值太大时，计算联动关系需要的内存会很大，对客户端的压力会增大，所以我们将过滤组件和参数组件默认显示的值设成了最大是1万。如果用户将系统的这个属性改成了10万，会将此信息收集到报表制作的系统原因中。

在报表端我们会做各种计算，比如绑定了报表端新建的计算列，组件上的分组和汇总，组件上的过滤等。一旦有任何一种计算不能下推到数据库或集市进行计算，我们会将其收集到报表原因中。还有一些报表制作的原因，比如正常情况下，不会查询全量数据，对于小张的例子来说，默认情况下他只用查询本年度的财务报告就可以了，所以他完全可以在筛选条件上设置默认值为本年，这样会大大加快报表打开的速度。所以对于查看报告时，查询全量数据的情况，我们也会及时提醒并给出建议。

报表的数据绑定依赖于数据集，当数据集（SQL数据集/自服务数据集/组合数据集）上有不能下推到数据库执行的列/操作或者过滤中的过滤条件不能下推到数据库中执行时，会将此信息收集到数据集原因中。