1. 概述
1.1 应用场景
在使用填报过程中，可能会出现一些性能问题，比如提交慢，页面加载慢，导入 Excel 慢，控件操作卡顿等。本文档针对这些常见场景，结合产品现有的逻辑进行分析，帮助大家更好的发现和解决填报性能问题。
2. 填报页面加载慢
问题描述：
填报预览的页面，相较于分页预览方式，加载时间明显变长。
填报预览的页面，插入删除行时加载较慢。
注：如果分页预览加载也慢，可以参考模板性能问题排查方法排查。
2.1 数据量过大
原因分析：
由于填报预览默认不分页，所有数据和元素都在一个页面上展示。所以当数据量较大时，页面元素也会很多， 就有可能造成页面加载慢。
解决方案：
1）通过查询条件控制每次查询的数据量
2）使用「填报分页」功能
2.2 控件直接显示
原因分析：
开启「直接显示控件」功能后，会明显增加浏览器的渲染压力。
此外，如果单元格控件存在数据字典且有默认值，则每一个控件都会在页面加载时发送请求去获取数据字典信息，导致加载缓慢。
注：例如按钮控件、复选按钮控件、单元格按钮组控件等，不会受到「直接显示控件」设置的影响，默认始终直接显示，会出现上述问题。
解决方案：
1）关闭「直接显示控件」，尽量不使用按钮控件、复选按钮控件、单元格按钮组控件
2）通过查询条件控制每次查询的数据量
3）使用「填报分页」功能
4）不设置单元格控件的默认值
2.3 页面使用了 sql()、ds1.select()、value() 等取数函数
原因分析：
同条件下，取数函数的性能排名为：value()>ds1.select()>sql()，如果使用了性能较差的函数，且数据量较大的话，会造成页面加载缓慢。
解决方案：
1）优化 sql 本身的速度
2）使用 value() 函数
3）通过查询条件控制每次查询的数据量
4）使用「抽数缓存」优化取数速度
2.4 插入行局部刷新
3. 控件操作卡顿
问题描述：
控件在输入值或者选择值之后，页面会长时间卡顿。
3.1 控件数据字典数据量大
原因分析：
带有数据字典设置的控件，如果数据量较大，模糊搜索就会比较慢。
解决方案：
参考下拉框数据量大时模糊搜索慢的方案处理。
3.2 控件存在联动
原因分析：
如果控件输入数据后，需要联动其他控件数据字典/单元格或者写了 JS 进行一些自定义处理，而被联动的内容较慢的话，就会导致卡顿。
解决方案：
1）优化被联动的内容，减少多余的联动设置。如需要使用取数函数，尽可能用 value() 函数。同条件下，取数函数的性能排名为：value()>ds1.select()>sql()。
2）使用「抽数缓存」优化取数速度
3）如果是用JS给其他单元格赋值，且赋值的数据量较多，可以换用批量赋值接口，具体用法可参考：JS实现复选按钮控件全选和批量操作中的2.5一节
3.3 控件值校验慢
原因分析：
带有数据字典设置的控件，设置了「不允许自定义值」后，每次输入值都会触发该校验，去对应的数据字典搜索。如果数据量大，就会导致卡顿。
解决方案：
勾选「允许自定义值」，并将相关校验放在「填报属性」的「数据校验」设置中实现。
4. 数据校验慢
问题描述：
点击数据校验，页面卡住无响应。
Excel 批量导入速度慢（Excel 批量导入包括了校验和提交2个过程）。
4.1 数据校验过多/过于复杂
原因分析：
在数据量较大的情况下，如果设置了较多/较复杂的校验公式，例如包含层次坐标，取数函数(sql()、ds1.select()、value()等)的公式，就会导致校验卡顿。
解决方案：
1）同条件下，取数函数的性能排名为：value()>ds1.select()>sql()。在条件允许的情况下，尽量使用value函数来取数，同时优化数据集sql本身的执行速度。
2）使用 「抽数缓存」优化取数速度
3）在校验公式无法简化和减少的情况下，可以考虑分批次提交数据，减少每次提交的数据量。
4.2 不符合校验条件的数据过多
原因分析：
存在不符合校验条件的数据时，系统会标注出对应的单元格，方便用户识别和修改。但如果不符合的数据太多，标注过程会占用较多渲染性能，造成页面卡顿。
解决方案：
此情况较少，可使用「填报分页」优化，但分页后不符合校验的标记只对当前页生效。
4.3 控件的自定义值校验慢
原因分析：
11.0.2版本开始，点击数据校验或者提交时，会校验所有控件的「允许自定义值」设置。当控件数据字典中的数据量较大时，该校验过程会占用比较多的时间。
解决方案：
1）如果不需要在提交时校验控件的「允许自定义值」设置，可以在finedb的FINE_CONF_ENTITY表中添加字段WriteOptimizationConfig.verifyCustomValue=false来回退逻辑，使得提交时不再校验该项设置。
2）如果需要在提交时校验控件的「允许自定义值」设置，目前没有特别好的方案，可以考虑减少数据字典的数据量，或者将相关校验放在「填报属性」的「数据校验」设置中实现。
5. 数据提交慢
问题描述：
点击数据校验速度较快，但点击提交速度较慢。页面一直显示加载中，甚至崩溃无响应。
Excel 批量导入速度慢（Excel 批量导入包括了校验和提交2个过程）。
5.1 数据量建议
原因分析：
在服务器硬件较好，且填报模板为简单结构的情况下，目前能支持的提交数据量（行*列）上限在100w左右。在此范围内，数据量越多，提交的时间也越长。
解决方案：
尽量控制一次提交的数据在100w内。如果超出了，可以考虑分批次提交，减少每次提交的数据量。
5.2 数据表已有数据影响了更新和删除速度
原因分析：
当提交类型为智能提交、删除提交、更新提交时，在执行提交过程中会发送带有where关键词的sql语句去根据主键找到对应数据，所以如果数据表已有部分数据，则该查询动作可能耗时较长，影响整个提交的速度。
解决方案：
1）如果只需要插入数据，将提交类型改为插入提交。
2）如果需要更新和删除数据，则根据填报属性中设置的主键，去数据库给对应字段增加索引。索引覆盖的字段数量和顺序都需要和填报主键字段一致，否则无法发挥效果。（优先推荐）
注：可通过测试插入提交的速度来确认问题原因是否为此项，如果同样数据插入提交较快，其他提交较慢，则大概率为此原因。
5.3 数据库自身存在性能问题
原因分析：
如果数据库本身性能不是很好，也会影响提交速度。
解决方案：
1）优化数据库设置
2）更换数据库
3）若入库的数据库类型为 MySql，可以通过在 MySql 数据连接的 URL 后增加 rewriteBatchedStatements=true参数来开启 MySql 数据库的批量提交功能，从而提高提交性能。格式如下：
若 URL 中未添加过参数，直接加 ?rewriteBatchedStatements=true
若 URL 中已添加过参数，最后加 &rewriteBatchedStatements=true
5.4 数据库表被锁
原因分析：
如果提交入库的表因为某些原因被锁了，则可能导致长时间提交不入库。此时日志中会出现类似于Lock wait timeout exceeded等带有lock的报错。
解决方案：
在数据库检查入库表是否被锁，解锁后再提交。
5.5 页面数据存在笛卡尔积
原因分析：
模板父子格设置不合理，造成数据以数组*数组形式提交，提升了提交的数据量和时间。
出现此问题时，提交时页面会提示存在笛卡尔积，日志中也会出现BatchDML,one of FArray的提示。
解决方案：
根据报错中提示的字段，调整其所在单元格的父子格关系。不建议开启「允许填报笛卡尔积」，其并不能提升性能。
6. 导入Excel慢
问题描述：
导入 Excel 时间较长，甚至页面崩溃无响应。
6.1 渲染慢
原因分析：
导入数据量大时，会明显增加浏览器的渲染压力。且如果开启了「直接显示控件」，则会进一步增加渲染压力，导致导入缓慢。
注：例如按钮控件、复选按钮控件、单元格按钮组控件等，不会受到「直接显示控件」设置的影响，默认始终直接显示，会出现上述问题。
导入时可以通过以下加载动画的时间来确认是由于渲染慢导致。
解决方案：
1）使用「填报分页」功能进行预览和导入 （优先推荐）
2）关闭「直接显示控件」，尽量不使用按钮控件、复选按钮控件、单元格按钮组控件
6.2 计算慢
原因分析：
在导入时，会对页面上的公式进行计算。如果公式复杂，或者涉及取数函数（sql()、ds1.select()、value()等）的话，则可能会影响导入速度。
导入时可以通过以下加载动画的时间来确认是由于计算慢导致。
解决方案：
1）同条件下，取数函数的性能排名为：value()>ds1.select()>sql()。在条件允许的情况下，尽量使用value函数来取数，同时优化数据集sql本身的执行速度。
2）减少需要在页面上计算的公式数量，降低其计算复杂度。
3）使用「抽数缓存」优化取数速度 。
