1 首先，一個很基礎，但是發現還是有人忽略，導致問題也比較嚴重的問題。就是服務日誌不能存到跟業務資料庫裡面，就算是分庫也會受影響，最好就是完全隔離。存到獨立的元件裡面，業界比較流行就是ELK了，各種雲服務也是在ELK上面改進而來。如果不這樣做，首先日誌儲存到業務資料庫裡面，相當於變相人為給資料庫加重幾倍業務壓力。通常一個業務請求有N條日誌，也就是資料庫承載了業務乘以N的壓力。 第二，資料量大，也意味著空間大，浪費業務寶貴的儲存空間，日誌不需要太及時，也不需要長期儲存，但是短期又要大量儲存。第三，查詢日誌困難，統計類查詢慢，日誌裡面有很多json格式資料檢視比較難看出結果，查詢慢卡頓，影響業務。

2. 慢查詢，這種一般是比較容易發現的問題，通常新增索引即可。需要注意，多個條件查詢要建立組合索引，因為儘管你每個欄位單獨建立索引，命中索引只會命中一個索引，其他條件查詢裡面特別是有排序的話，會產生filesort 這種耗時操作，如果索引有中包含了排序的欄位，天然結果就是有序的。

3. 慢查詢排除完了，但是CPU很高，甚至到90%。如果是業務增長了，快速的解決方法是升級硬體，雲服務可以做到無縫升級配置而不影響業務，其他雲服務有一個數據遷移的過程。

4. 快速升級完硬體，如果發現併發 show proceslist ，QPS不高，也沒有慢查詢，那當時cpu這麼高，而且大部分都是select 查詢，那麼初步可以判斷是select裡面是掃描比較多的行資料，這個一般可以通過雲服務的全量統計功能可以發現mysql的執行狀況，主要看聚類sql模板，看哪一種佔總耗時比較多，掃描行數比較多，平均耗時比較多。大部分的簡單select 操作都是0.1毫秒級別的。通常就是一些join 連表查詢裡面，對應連線欄位沒有建立索引。因為mysql有執行計劃，在本地資料量比較少的情況下，有可能只命中比較簡單的索引，但是在資料量大的真實環境，如果你建立了組合索引，還是可以命中。目前的組合索引是 查詢條件的欄位在前，後面帶上連表的欄位，還有查詢的欄位。優化後，cpu也從40%降到了2%-3%. mysql.innodb_rows_read person second行讀數，InnoDB快取請求次數(mysql.innodb_buffer_pool_reads_requests)也跟著cpu 大幅度減少， 但是QPS，TPS保持不變。