24.性能优化配置

1.弹性模型

1.模型的本质是什么？

模型的本质就是一张表格，可以给他理解为一张excel 表格，只是不同类型的模型取数据的地方不同，有的来源于数据表，有的来源于json文件，还有的来源于后端逻辑拼接的

2. 标准弹性模型的特点是什么？

数据都来源于 hcm_flex_model_data 这个数据表

通过 model_name 来区分不同的模型数据

3.弹性字段是怎么实现的？

拓展的字段存在data里面 data为json 字段，数据库常用的字段有哪些呢 integer类型 string类型，boolean类型，text类型，datatime 类型， json 类型
json 类型是数据库中存的是json字符串 {"a":1,"b":2,"c":"wq"}
既然是json 字符串理论上来说它是无限大的，可以存储很多数据，实际上它是有限度的，但是这个限度绝对在我们使用范围内，可以放心使用
弹性字段够我们使用，它的缺点也是很明显也就是效率问题，弹性字段需要从data 里面解析出来，这样就会消耗时间，性能不佳，连表查询尤为缓慢
缓慢的其中一个原因呢是弹性字段不能使用索引

2.性能优化--映射实体字段

1. 哪些模型实现了实体字段映射呢

1.标准弹性模型

2.EmployeeEducation 教育信息模型

3.TechnicalSkills  技术技能信息模型
4.EmployeeSubSetFlexData 人员信息子集
5.SalaryDataEntry 薪酬明细数据 模型
6.WorkFlowFormDataFlexData 流程数据
7.WorkFlowFormDataChildFlexData 流程子表

2.背景

标准弹性模型如果数据量比较大，一些弹性字段使用过滤，排序，关联等操作速度很慢，性能很差，我们将会把该字段升级到标准字段里面

3.操作

a.修改弹性字段

可以选择一个实体字段，这个实体字段就是即可，一旦选中保存不可修改

升级接口 hcm.db.flex.field.flex.model.update.mapping.entity.field 参数为 {"model_name":"xxxx"} 模型名称

调用该接口的目的是将已存在的数据进行升级

流程相关的表升级接口为流程数据表接口 workflow.mapping.entity.field 传入的参数为 {"business_id":xxxxx}

例如：wf_form_data_flex_data.10001 business_id 为10001

流程子表升级接口为 workflow.mapping.entity.field.child 传入的参数为{"business_id":xxxxx，"detail_key":xxxx}

例如：wf_form_data_flex_data_child.12#detail business_id 就是22 detail_key就是detail

4.操作前请思考

1.是不是只要升级了字段速度就一定会提升呢？

答案是否定的，我们要讲究策略

2.什么样的字段需要升级字段？

首选有关联的，第二选需要过滤的，第三选排序的，预制字段有限选前三思

3.多个弹性字段选择映射时是否有策略？

有策略，对于弹性模型 data_object_id ，data_object_key1 搭配使用效果最好

好刚用在刀刃上 data_object_id，data_object_id2，data_depart_id，data_object_key1，data_object_key2，data_effect_date

不要单独使用 data_effect_date

剩下的字段效果不明显

5.快速检查需要配置的字段小妙招

3.性能优化--表关联优化策略

背景

list页面速度慢数据库压力较高可能造成数据库崩溃/数据库整体性能不佳

配置说明

list 元数据配置 relation_mode

	force_not_used_table	1.强制去掉所有没有使用的表 2.对于count sql未做特殊处理
relation_mode		特点
	least_relation_all	1.需要relations内部配置ondemand，不然只去掉type未outer的 2.对于count sql 做了特殊处理去除排序和字段的规则
	least_relation_all_root_filter	1.需要relations内部配置ondemand，不然只去掉type未outer的 2.对于count sql 做了特殊处理去除排序和字段的规则 3.根节点权限不过滤
	least_relation_all_root_filter_sort	1.需要relations内部配置ondemand，不然只去掉type未outer的 2.对于count sql 做了特殊处理去除排序和字段的规则 3.例如左树的页面 list去掉排序 4.根节点权限不过滤
	manual	1.需要relations内部配置ondemand，才会起作用，不然不去掉关联， 2.对于count sql未做特殊处理

relation_mode	ondemand	按照我们的需求来去掉
relation_mode	null	不会去除

必须字段

conditions 使用到的字段。 
filter_dict 使用到的字段
fields 查询的字段
sorts 排序的字段

页面树结构