这篇指导内容，主要是为了帮助现场的老师解决列表页面或者报表加载速度慢的问题；
当觉得页面加载（主要是model.list接口）慢时，可以根据这篇wiki的内容，先自行进行排查和初步优化，基本上就能解决80%以上页面加载慢的问题。
一. 通用关联优化
不管是通用的列表取数还是报表数据源取数，都避免不了与其他模型配置关联。
一般导致列表页面或报表加载速度慢的主要原因就是表关联过多，或者没有正确使用的表关联。
1.检查是否所有关联都是必须的。
在项目现场的配置中，很多配置常常都是成段的拷贝过来的，所以可能会出现很多非必要的关联，这时候就需要逐一排查
合并元数据，查看是否关联的所有表在当前页面都有用到。
比如以上截图中的三个模型，可以查看列表页是否必须展示这三个模型上的某个字段信息，如非必要，可以通过配置meta_disabled:true取消该模型的关联
注意：在报表中直接关联组织层级表的时候，通常通过岗位的parent_id关联部门表的origin_id，再通过部门表的origin_id关联组织层级表的department_id。
这个关联，假如报表页面关联组织层级只为过滤，页面上不需要展示除部门名称外的其他部门表信息时，可以考虑直接用岗位parent_id关联组织层级表department_id，简化一层关联，速度就会有明显提升，部门名称的展示可以通过岗位的parent_id来展示。
2.表关联优化
在表关联中，有一个type属性，配置值有inner(内关联)/outer(外关联)，在不配置的情况下默认为inner。
注：在数据库中，外关联又分为左连接，右连接和全外连接。我们系统中的outer表示左连接（其他的不做赘述，感兴趣的可以自己扩展查询）
inner：内连接，只取两张表的交集部分。比如人员与任职表采用内连接，如果一个人没有任职，那么列表中就不会展示出来该条数据。
outer：外连接，会将左表（主表）的内容全部展示出来，不管右表是否存在数据。比如人员与政治面貌关联，不管这个人政治面貌是否维护数据，都不影响该人员的展示。
如果说右表存在多条数据，那么不管是外连接还是内连接，都会展示多条数据。
比如用人员关联教育经历表：1、如果一个人有三条教育经历数据就展示三条数据。
2、如果一个人没有教育经历，内连接就会一条数据都没有，但是外连接会展示一条数据。
在了解以上基础上，针对外关联的表，有一个ondemand的参数，这个参数需要配置在relations的具体关联中，用来单独定义每个关联的优化模式。
配置示例：
ondemand参数目前支持两种模式：1和2。
在一般list接口中，会向数据库请求两次sql。一次请求数据的数量(count)，一次请求具体的数据(list)。
- 模式1：在两次sql中，如果判断当前外关联的模型在本次请求中没有被用作过滤/模糊搜索/字段展示/排序，那该模型就会被默认取消关联，用以优化数据查询速度。如果模型被用到，就还是正常查询，不会影响到我们这次查询数据。
- 模式2：在1的基础之上,如果模型没有被用作过滤/模糊搜索，但是可能被用做了字段展示或排序，这种情况下，请求数据数量的sql会把该模型优化掉，但是查询具体数据信息的时候不会优化掉。这种情况可能会导致请求结果返回的count和list数据不一致（但是事实上我们系统内大部分的场景都可以直接用2，因为大部分关联场景的数据量都由主模型决定，或关联模型已经被用作过滤，所以不会被优化掉，因此也不会影响count数据）。
总结
针对外关联的表，你只需要考虑，如果我去掉这张表的关联，会不会影响到整体数据的数量，
如果确定对数据量不会产生任何影响，就直接大胆的配置ondemand:2，那我们系统就会自动在该优化的地方做好优化。
至于会影响到数据量的情况，一般不做优化。
配置方式
- 列表页面:list元数据配置-合并元数据-查找relation-分析需要添加优化的模型-配置
- 报表数据源
备注：不管是报表还是列表，都优先采用上述方式进行优化，对系统影响最小并且效果也最明显。
二. 表优化
表优化操作，通常是在我们已经使用ondemand关联优化模式进行优化后，发现页面加载速度还是比较慢时，会进行的后续处理操作。
这时候通常的问题可是，模型内存在弹性字段关联或过滤的情况，所以需要使用表优化（弹性字段映射实体字段）的方式进行优化。
1. 优化方式一：映射实体字段
这里需要强调一下，并不是所有的实体字段映射效果都很明显。
2. 优化方式二：模型持久化
这种一般只支持私有云，直接参照wiki
三.报表优化
分析报表计算或导出速度慢可以查看报表页面的进度条，一般都是卡在数据源计算或者公式计算上面。
1.分析数据源优化
- 查看报表中有没有实际用不到的数据源，如果有直接删掉：报表在计算时默认会计算全部的数据源
- 如果是自定义数据源参照上方通用数据源关联优化方式
缓存优化
仅适用于《汇总表》以及《分析报表/仪表板中数据源的取数类型为统计》的情况下
这种优化模式是将相同配置信息的报表计算结果缓存下来，时效为24小时，所以数据会存在一定的延时，在数据量巨大且没有别的优化空间时才考虑这种方式
配置方法：
分析报表或仪表板的数据源的高级：
汇总表设置：
配置"cache_support": true
2.公式优化
报表内公式过多的情况也会导致计算卡顿，如果是行展开报表，那计算及导出是需要计算的公式个数约等于：数据量*公式个数，因此设计报表时能避免公式则避免
针对vlookup和vlookstat公式不可避免的情况下，可使用数据源合并公式(MULTI_LIST_CONCAT)进行优化,其目的就是在数据源计算的时候就将多个数据源的计算结果合并成同一个，在报表模板中直接通过{字段}的方式取值，从而减少使用vlook公式
列表合并公式
MULTI_LIST_CONCAT(refer_list, left_fields, list_define)
Args:
refer_list: 主数据块
left_fields: 主数据块合并字段列表 ['employee_id']
list_define:合并数据块定义, 可以支持多个合并数据块， 两种类型：list(直接列表合并, 用与替换vlookup公式)/aggr(统计后合并， 用于替换vlookstat公式)
[{
"type": "list" # 列表
"suffix": "a" #后缀，新列表中字段修改
"list": [], # 数据源a
"filter_str:"", #固定过滤条件, 写法同vlook公式
"fields":[], # 字段列表，合并依据，可以写多个， 与left_fields一一对应
"merge_fields": [] # 被合并字段列表
"keep": "first/last" # 相同数据取第一条还是最后一条, 默认第一条
}，
{
"type": "aggr" # 统计
"list": [], # 数据源b
"filter_str:"", #固定过滤条件, 写法同vlook公式
"fields":[], # 字段列表，合并依据，可以写多个， 与left_fields一一对应
"aggr_fields"： 统计字段，支持多个， 写法：[(别名, 字段明, 统计类型)]示例:[("min_salary", "salary_real", "min")]
统计类型支持
mean Compute mean of groups
sum Compute sum of group values
size Compute group sizes
count Compute count of group
std Standard deviation of groups
var Compute variance of groups
sem Standard error of the mean of groups
describe Generates descriptive statistics
first Compute first of group values
last Compute last of group values
nth Take nth value, or a subset if n is a list
min Compute min of group values
max Compute max of group values
}]
四. 运营者模式
如果通过以上方式仍然无法达到优化的目的，可以寻求开发老师帮助，但在此之前，需要通过运营者模式将页面速度慢的接口信息发送给开发老师，接口信息可以通过打开运营者模式获取，具体操作参照wiki:07 开发者模式及运营者模式介绍#%E8%BF%90%E8%90%A5%E8%80%85%E6%A8%A1%E5%BC%8F