普通碼農寫代碼，沒有性能優化，當數據量變大，效果就很明顯了。接口響應時間過長，導致客戶體驗效果非常差。
首先，從最外層開始，瀏覽器按F12，看看Network哪個接口占用時間最長（也有可能存在一些CSS或JS插件一直請求不到導致的時間過長），然後進接口分析你的邏輯代碼，一行行審代碼，找到耗時的地方進行邏輯優化，最後找到sql去執行下，看看時間是否很長，可以參考下https://blog.csdn.net/Pagegle/article/details/103529738來進行鍼對性優化。數據量很大很大的話能分表就分表，能分庫就分庫（這個忘記記錄了，可以參考sharding-jdbc的分庫分表使用）。如果前面的都沒問題，那可能就是網絡原因了。
下面根據我的實際情況講講優化過程。 一、數據庫優化 我是查詢接口訪問過慢，達到了36724ms，什麼概念！！！因爲我爲了查詢方便，不想寫太多代碼，我就將主表和其他一些子表、字典表的數據整合在一起，做了個視圖，但是我沒有對其視圖邏輯進行優化，導致查詢時間較長，數據量越多越慢，再加上使用的JPA的findAll方法，累計起來時間就很長了。參考上一篇對MySQL視圖進行優化使用explain解釋語句，對Extra中是“Using temporary; Using filesort”的語句進行優化。
優化前：
優化後：
二、縮小數據包 在使用SpringMVC轉Json的時候，會把沒有值的字段用Null來佔位，這樣的話，其實是把一些數據變成了Null。雖然小了，但是還是會佔用空間。我們可以在Json序列化時忽略Null屬性，可以給類頭部加上@JsonSerialize(include=JsonSerialize.Inclusion.NON_NULL)，這樣就可以讓SpringMVC把Null屬性不採用序列化，且gson包也支持空值不序列化。 優化前：
優化後：
數據包是小了，時間可能因爲是測試環境數據量太少效果不明顯
後面有其他方法再記錄