一、DB優化
SQL查詢走索引
拆分復雜SQL
讀寫分離
二、業務優化
Log4j2異步
緩存(Redis)
業務異步處理
循環內不要操作數據庫、緩存
sleep絕對不允許
批量獲取數據
用空間換時間
合理使用事務
下面逐步拆分每種情況的優化分案：
1、所有的SQL查詢盡量走索引，不要全表掃描。把SQL都放到數據庫中看一下執行計划。比如，使用mysql可以把每條SQL前加上explain，看一下執行計划
2、不要寫復雜的SQL，不要將業務邏輯拋給數據庫去處理，應在程序中處理這些業務邏輯，數據庫只是用來取基礎數據，盡可能的單表查詢走索引，拿到數據之后根據業務需求在程序中處理
3、數據庫要讀寫分離
4、盡可能的去掉無用日志，代碼寫的規范不用過多的日志，看代碼就知道業務邏輯。
5、循環內部不要有數據庫、緩存操作，把這些操作都移到循環外，通過批量的方式一次性獲取數據，然后在程序中對這些數據進行處理，轉換成想要的格式。比如，
①. 不要在for循環內執行 orderInfo.getById(id)，而是在循環外執行 orderInfo.batchById(List)，然后把返回的數據以id做key，每行記錄做value存儲到Map中，循環內只需要根據id就可以獲取到每條記錄。
②. 不要在for循環內執行 redisTemplate.hget(key,field)，而是在循環外執行 redisTemplate.hmget(key, fieldList)，一次性的獲取所有值，按照順序獲取每個值就OK了。
6、代碼中絕對不能寫sleep。
7、把耗時並且不影響業務主流程的邏輯異步處理，啟用線程去處理這些業務。比如，用戶每次下單前都需要自動釋放上一筆沒有支付的訂單，像這種情況可以啟動一個線程單獨處理，並且不用等待線程的返回接口。
8、一個大的業務方法中，各子模塊相互獨立，互不依賴，可以考慮使用並發處理，即多線程並發查詢數據。有個前提是該接口應至少高於20ms,如果再低,線程切換等因素可能會抵消掉多線程帶來的性能提高。比如，首頁接口需要返回3塊數據，每塊都是獨立的，並且都比較耗時，所以可以啟動3個線程同時獲取數據，最后等待每個線程返回結果。
9、業務數據增加Redis緩存。這是減少數據庫查詢，提升TPS的有效手段。但是要根據實際業務情況來使用Redis，合理的設計好緩存key的結構，避免緩存重復數據浪費空間。使用緩存的時候需要注意緩存穿透、緩存雪崩等問題。
10、異步執行任務的時候需要使用線程池，不能直接創建線程並啟動。創建線程池時需要使用無界隊列，若使用有界隊列，當並發量大，並且等待線程超過隊列大小時就會報錯，線程無法放入隊列導致任務丟失。