專案中存在問題

資產變更通知模組，使用者在配置了變更通知之後，系統會根據該表的血緣資訊生成一個附件，附件內容為該表所影響到的下游資料資訊。
因為公司的資料體量大，表的血緣資訊也比較複雜，某一張表的資訊影響到的下游都有十萬張表。因此在生產Excel的過程，使用者需要等待十多分鐘。

分析以及優化

因為某一張表的血緣資訊時呼叫其他服務的資料得到的，返回的數量級都是以萬為單位計算。
例如：其他微服務返回五萬條資料，我拿著這五萬條資料進行查詢mysql資料庫，補充資訊，生成Excel。分析這個Excel生成過程，耗時地方，在下方羅列出來

• 呼叫其他微服務返回這五萬條資料耗時。
• 查詢mysql資料庫，封裝填充Excel的資料 list。
• 對查詢出來的 list 進行進一步的補充。（當時直接忽略）

我的分析

• 使用postman直接測試對方提供的介面，結果很快。
• 我就想當然的認為那就是查詢mysql資料庫耗時，因為資料量比較大。

我的優化

把返回的資料分批查詢，每次查詢一千條資料，最終把查詢資料放入list集合。

注：因為開發測試都是沒有資料，我們只能去灰度驗證，大佬建議我把每個階段的耗時打印出來，因為我比較自負，認為一定是那個查詢資料庫操作耗時，因此我也只是列印了整體過程的耗時。

結果

優化前後耗時基本一樣

在別人的幫助下開始優化

分析定位：

• 呼叫其他介面資料耗時測試
• 查詢mysql封裝Excel的資料list
• Excel有一列是使用者資訊，只能通過程式碼額外補充，不能通過第二步查詢資料庫得到。
  程式慢的原因主要在第三步：補充使用者資訊，因為補充使用者資訊，做了查詢資料庫的操作，而且是在迴圈中查詢資料庫
  。

啟示

態度

• 態度問題，自己總是認為如果開發，測試有資料我也可以定位到問題，外部環境固然有影響，但是要明白，外部環境就是這樣，有可能還差。難道就不能定位問題，解決問題了嗎？必然是可以的，這是一個態度問題。
• 不能想當然認為，要認真分析問題，解決問題。

技術層面

• SQL 層面的優化
• 程式碼邏輯優化
• 迴圈中之中不查資料庫，在迴圈之前要準備好所需資料