優化標准：少於1s
可用apifox跑接口，看耗時多少ms
1.代碼執行慢：代碼優化
2.查詢數據慢：慢sql優化
如果已優化過，依然很慢，得分析是否是表數據量過大，譬如以前我們dba推薦mysql庫單表行數量不要超過3kw，實踐中也發現，當單表數據量過大時，單純從sql優化的角度着手是無法解決性能問題的。此時可能得考慮分庫分表，或采取其他的存儲方式
3.緩存優化（總之，能查詢緩存的話（redis），盡量不要直接查詢數據庫）
慢sql優化
1.單業務單sql 復雜邏輯用代碼處理，不放在sql里處理
簡單干凈的sql有利於降低數據庫開發的出錯率，集中業務邏輯於java代碼中，有利於與持久層的解耦，有利於開發與維護。
2.考慮redis緩存
3.加索引（二分法）：
4.條件太單一，建議加上過濾性高的搜索條件
5.列越少越好，大字段（varchar>100）列去掉
索引的介紹：
索引（Index）是幫助MySQL高效獲取數據的數據結構。提取句子主干，就可以得到索引的本質：索引是數據結構。
一般來說，索引本身也很大，不可能全部存儲在內存中，因此索引往往以索引文件的形式存儲在磁盤上。這樣的話，索引查找過程中就要產生磁盤I/O消耗，相對於內存存取，I/O存取的消耗要高幾個數量級，所以評價一個數據結構作為索引的優劣最重要的指標就是在查找過程中磁盤I/O操作次數的漸進復雜度。換句話說，索引的結構組織要盡量減少查找過程中磁盤I/O的存取次數。下面先介紹內存和磁盤存取原理，然后再結合這些原理分析B-/+Tree作為索引的效率。
聚集索引：表中各行的物理順序與鍵值的邏輯順序相同，每個表只能有一個。
非聚集索引：非聚集索引指定表的邏輯順序，數據存儲在一個位置，索引存儲在另一個位置，索引中包含指向數據存儲位置的指針。
索引的優缺點：
優點：加快訪問速度；
缺點：帶索引的表在數據庫中的存儲需要更多的空間；
下列情況下可以使用索引：
該列頻繁用於搜索；
該列用於對數據進行排序；
下列情況下避免使用索引：
列中僅僅包含幾個不同的值；
表中僅包含幾行。為小型表創建索引可能不太划算，因為SQLServer在索引中搜索數據所花的時間比在表中逐行搜索所花的時間更長。