場景描述：
上周末，一直在開發的網頁突然加載很慢，連接遠程服務器也很慢，很多接口直接超時報錯（NewWork Error）。
解決方案：
1.最初以為是后端接口太耗時，對mysql的操作太頻繁，所以優化了兩個版本的后端接口，結果為：
| 測試條件 | 測試結果 |
| 本地數據庫+本地代碼 | 復雜查詢的接口平均耗時300ms、400ms |
| 遠程數據庫+本地代碼 | 復雜查詢的接口平均耗時1000ms左右 |
2.還可以接受，就沒有再優化了。過段時間，接口返回又變慢了，這時開始考慮是不是服務器性能的問題，原先的配置是1核2G的測試服務器，於是就升級了服務器配置，為2核4G，此時結果為：
| 測試條件 | 測試結果 |
| 原先服務器配置（1核2G） | 頁面加載超時 |
| 升級后服務器配置（2核4G） | 頁面加載超時 |
3.我以為升級服務器就能解決問題，沒想到第二天過來一看還是沒有改變。暈~~然后由於本地程序連遠程數據庫，耗時就增加了，懷疑是網絡帶寬問題。當時用Navicat查詢遠程服務器測試了一下，一張表里就3條數據，加載到本地也要4-6s。此時在本地跑程序，連接遠程數據庫，報錯為Usemql的問題，同時查看mysql的連接數，有很多sleeping的連接，而且默認最大連接數150，已經用的差不多了。懷疑是程序異常后沒有關閉業務連接，測試了一下，產生異常后用save()關閉連接，用show full processlist比較數量，結果沒有變化。。還是覺得是帶寬問題。
4.和老師，師兄一起研究了一下，用nload工具查看網絡情況，同時把進程一一關閉（由於服務器上有多個程序）。確認是我的后台程序占用帶寬，一直在進行數據的上傳和下載。同時查看服務器的網關，只有一個網關eth0，限制帶寬為5M。此時老師建議我，把數據庫連接語句中的IP地址設置為127.0.0.1，由於數據庫和程序是在同一個服務器上，但一開始我是用數據庫的外網地址去連接的。數據傳輸時可能走的是外網的網關，受到帶寬的限制，本地IP則用本地網關，沒有帶寬限制。一改，好了！這。。。確實學習到了。
放一下結果：
| 測試條件 | 測試結果 |
| Postman測試查詢接口 | total耗時78ms,Transfer 耗時62ms |
總結：
程序連接數據庫時，如果是在同一內網或同一服務器，盡量用內網IP去連接。畢竟受帶寬限制。