>[info] # 背景 - 数据表 - q_policy_enterprise 政策可申报表 - q_policy_apply 政策已申报，已获批表 - q_policy_enterprise_view （由q_policy_enterprise + q_policy_apply 两个表构建出来的视图） - 给30W企业打行业标签， 通过第三方接口同步可申报数据， 600W+的可申报数据， 导致接口查询慢 - 对数据库表进行优化 去掉q_policy_enterprise， q_policy_enterprise_view两张表，合并到 q_policy_apply表 - 通过type 字段区别 1已申报 2已获批 3可申报 - 在 q_policy_apply 表 增加 policy_uuid 字段，原先的 policy_id 字符串类型的， 也会导致查询缓慢 >[info] # 涉及改动 全局搜索修改 原先用到 q_policy_enterprise_view 表的要改成 q_policy_apply 原先用到 q_policy_enterprise 表的要改成 q_policy_apply && where type=3 原先用到 q_policy_apply 表的要加个条件 where type in (1,2) policy_uuid 换成 policy_id - ViewType int `json:"view_type"` //视角类型 1-个人视角 2-领导视角 3-部门视角（必填） -  - 下面的接口参考原先的逻辑进行重写, 重写的时候看下优化文档改动  >[info] # 已修改的 - 企业更新和一键申报的接口，涉及的修改，以及定时器已经修改了 - 代码分支： featrue-policy-winnie ~~~ group.POST("/click_declare", api.IndustryMapEnterprise.ClickDeclare) //新增 - 一键申报 group.POST("/enterprise_save", api.IndustryMapEnterprise.EnterpriseSave) //新增 - 企业更新 ~~~ - 企业数据更新的时候， 会重新匹配这家企业的可申报数据 - 一键申报的时候， 如果数据库表 q_policy_apply 存在可申报的数据， 申报的时候就修改这的数据的type, 如果数据不存在则插入新的 >[info] # 政策库的优化 - group.GET("/list_user_policy", api.Panorama.PolicyListUserPolicy) //列表-个人视角-政策列表（相关政策数进入） - 领导视角和部门视角的优化可以参考上面接口， 唯一的区别就是， 统计出来的可申报，已申报，已获批的数据要加缓存， 10个街道+1福田区个Key缓存结果