>[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緩存結果