历史版本3 :大数据量模板优化思路 返回文档
编辑时间:
内容长度:图片数:目录数:
修改原因:
1. 概述编辑
大数据量模板优化方法请参见：
2. 具体解决方案编辑
| 问题痛点 | 应用场景 | 解决方案 | 备注 |
|---|---|---|---|
| 减少格子数及格子数相同下的优化 | 行列调优 | 列转行 | 1）产品逻辑：格子数相同情况下，列越多，计算越慢 2）大数据情况下一个 sheet 100 行，比两个 sheet 每个 50 行要慢 3）列转行更多的是提供一种减少方向，尽可能减少列多的用法，运用到实际场景中可能有：减少交叉模板使用，专注使用行式明细模板 |
| 减少行列、格子数 | 1）通过取数限制减少行，如mysql 中 limit 100（如果有求和且需要保持全量可以用sql函数） 2）减少展示的列数 | 特例：遇到纵向列为id，横向行为时间的设计，数据源本来就1W行，最终格子数确是 1W（列数）*40（日期数），其中格子实际使用数不到3%，大片都是空白格 | |
| 格子内计算-公式 | 存在层次坐标、sql类函数 | 减少层次坐标、SQL 类函数（sql，value，map、select）在扩展行的使用 | SQL 类函数在即时取数时每一个行都会独立执行一遍sql、填报校验时同理 |
| 模板存在大量被公式调用的图片 | 1）安装 外置图片插件 、把内置图片都改为外置图片 2）单元格把数据转图片的方法的优先使用顺序：html>webimage>toimage>单元格图片 | - | |
| 格子内计算-控件 | 控件数量、使用可以简化的场景 | 减少控件使用，如纯导入模板，不配置控件 | 经测试发现，导入一个 200 行 10 列的 Excel，增加控件的模板需要 100 秒左右才可以完成页面加载，去掉控件的模板只需要 10 秒左右 |
| 控件数据字典优化 | 控件数据字典尽量用数据集并开启缓存，尽可能不要直接用数据查询 | - | |
| 控件默认值优化 | 1）简化或者去掉控件默认值 2）控件默认值，工具栏，加载事件中尽量不要用单元格如=A1 3）下拉树控件设置全选或联动时、不用sql函数，把sql函数的语句放在数据集里面，然后默认值里把sql函数的部分换成value | 控件里的参数默认值也是在初始化时计算的，不是在点击的时候才计算，如果按钮控件里大量调用sql函数，并且计算时间较久，也会对模板加载时间产生影响 参数面板控件默认值同样引发性能问题 | |
| 客户允许不开启直接显示控件 | 不开启直接显示控件 | 当一个页面的控件数量超过 100 个，就会拖慢页面展现速度，超过 500 就很容易造成超时 | |
| 格子内计算-控件相关 | js计算按钮控件里的参数默认值过久 | 修改js | 按钮控件控件里的参数默认值也是在初始化时计算的，不是在点击的时候才计算，如果按钮控件里大量调用sql函数，并且计算时间较久，也会对模板加载时间产生影响 |
| 条件属性中使用sql函数做控件联动 | 不要在条件中使用sql函数写sql语句，优化下sql的取数时间或者换用其他方式实现 | - | |
| 新计算引擎下拉树加载慢 | 数据量不多的情况下，可以换成多个控件联动实现需求 | - | |
| 下拉框控件联动 | 勾选允许控件直接编辑和允许自定义值 | 不勾选的话会读控件默认值，如果客户的控件默认值是写的数据集里的字段，且这个数据集也是有参数的，就会导致sql一直重读 | |
| 格子内计算-父子格 | 笛卡尔积 | 防止填报笛卡尔积 | 提交入库时如果重复提交了很多数据（不只重复一次），很可能是单元格的父子格设置导致成为笛卡尔积的形式提交了，所以需要检查父子格设置 |
| 模板扩展行支持使用统一左父格 | 所有格子尽量使用同一个父格、而不是依次继承 | - | |
| 过滤配置推荐 | 同一行不同格子设置过滤的时候，尽量只对第一个格子设置过滤 | - | |
| 列表、分组的选择 | 大数据量的明细模板，列表展示比分组快 | - | |
| 格子内计算-其他 | 条件属性实现隐藏行列、行变色 | 1）使用条件属性的时候，如果对单个单元格设置条件属性就能满足需求的情况下，就只对一个格子设置条件属性，不要对每个格子设置，例如隔行显示背景色，配合为整行生效。 2）如果可以直接隐藏行列，则不用条件属性隐藏 | - |