1. 案例：一條慢SQL拖死整個系統
某天突然發現服務探測接口瘋狂告警、同時數據庫CPU消耗也告警，最后系統都無法訪問；
起先以為服務出現問題，服務重啟后現象依舊；
后檢查數據庫發現，大量的慢SQL正在阻塞等待執行：
查看哪些表被鎖：show OPEN TABLES where In_use > 0;
查詢正在執行的SQL，發現大量SQL執行阻塞了幾百秒
select * from information_schema.processlist where db=' db_xxx ' and info is not null;
直接取出索引的進程ID，拼裝成kill語句，取出來執行，干掉阻塞中的索引進程。
select concat('kill ', id,';') from information_schema.processlist where db='db_xxx ' and info is not null;
發現干掉一次之后，很快又出現大量的執行阻塞的SQL，而且90%以上都是某一條SQL。
干掉N次之后仍然不行，還是會出現。。。。。。
將該條執行的SQL扒出來，針對查詢條件，創建了組合索引，SQL阻塞現象消失，
系統也恢復了正常。。。。。
2. CPU的消耗主要在 用戶、系統、IO等待、軟硬中斷、空閑。
主要針對用戶、IO等待進行優化（其他方面較難改變）
用戶: 用戶這塊主要是用戶空間CPU消耗，各種邏輯運算； 比如：正在進行大量tps
以及函數/排序/類型轉化/邏輯IO訪問…
IO等待：等待IO請求的完成
主要是這兩者消耗了大部分的CPU，導致吞吐量下降、查詢響應時間增加、慢查詢增加。
3. 減少CPU消耗
3.1 減少等待
減少IO量：創建適合的索引，空間換時間，提示慢SQL的執行速度。
提升IO處理能力：加大cache、加大磁盤/SSD
3.2 減少計算
1) 減少邏輯運算：
避免使用函數，將運算轉移至易擴展的應用服務器中
如substr等字符運算，dateadd/datesub等日期運算，abs等數學函數
減少排序，利用索引取得有序數據或避免不必要排序
如union all代替 union，order by 索引字段等
禁止類型轉換，使用合適類型並保證傳入參數類型與數據庫字段類型絕對一致
如數字用tiny/int/bigint等，必需轉換的在傳入數據庫之前在應用中轉好
簡單類型，盡量避免復雜類型，降低由於復雜類型帶來的附加運算。更小的數據類型占用更少的磁盤、內存、cpu緩存和cpu周期
2) 減少邏輯IO量:
index，優化索引，減少不必要的表掃描
如增加索引，調整組合索引字段順序，去除選擇性很差的索引字段等等
table，合理拆分，適度冗余
如將很少使用的大字段拆分到獨立表，非常頻繁的小字段冗余到“引用表”
SQL，調整SQL寫法，充分利用現有索引，避免不必要的掃描，排序及其他操作
如減少復雜join，減少order by，盡量union all，避免子查詢等
數據類型，夠用就好，減少不必要使用大字段
如tinyint夠用就別總是int，int夠用也別老bigint，date夠用也別總是timestamp
減少query請求量
適當緩存，降低緩存數據粒度，對靜態並被頻繁請求的數據進行適當的緩存
如用戶信息，商品信息等
優化實現，盡量去除不必要的重復請求
如禁止同一頁面多次重復請求相同數據的問題，通過跨頁面參數傳遞減少訪問等
合理需求，評估需求產出比，對產出比極端底下的需求合理去除
3.3 升級cpu
若經過減少計算和減少等待后還不能滿足需求，cpu利用率還高，使用殺手鐧升級cpu（使用更快更多的CPU）