雖然mysql中的單表數據量不大，幾萬條，但是在併發事務（併發數100-200之間，瞬間搶坑位）控制下，導致CPU飆升，查詢該表的select也耗時很久。
1、查看了mysql的CPU飆升時，IO、連接數、帶寬、內存等監控指標都正常
再查看慢SQL，超過1秒的SQL沒有。
再看錶的設計，沒有設計索引，將索引加上，同時mysql配置增加到16G的配置，問題得到解決。
雖然單條SQL執行效率快，但是沒有索引的情況，在高併發的情況下，會出現搶佔資源，因而導致CPU飆升。
最好是現場show processlist；查看線程具體情況，explain分析SQL執行情況，採用的哪個索引，進行優化SQL。
2、mysql不同的事務隔離級別，加鎖的情況不一樣，mysql的select都是快照查詢沒有鎖的，除非指明 for update ,lock in share mode(其他事務不可修改)鎖
已提交讀（Read committed）：沒有加間隙鎖
可重複讀（Repeatable read）：事務是有加間隙鎖的
鎖機制
（之所以以InnoDB爲主介紹鎖，是因爲InnoDB支持事務，支持行鎖和表鎖用的比較多，Myisam不支持事務，只支持表鎖）
- 共享鎖（S）：允許一個事務去讀一行，阻止其他事務獲得相同數據集的排他鎖。
- 排他鎖（X)：允許獲得排他鎖的事務更新數據，阻止其他事務取得相同數據集的共享讀鎖和排他寫鎖。
- 意向共享鎖（IS）：事務打算給數據行加行共享鎖，事務在給一個數據行加共享鎖前必須先取得該表的IS鎖。
- 意向排他鎖（IX）：事務打算給數據行加行排他鎖，事務在給一個數據行加排他鎖前必須先取得該表的IX鎖。
InnoDB行鎖是通過給索引上的索引項加鎖來實現的，因此InnoDB這種行鎖實現特點意味着：只有通過索引條件檢索數據，InnoDB才使用行級鎖，否則，InnoDB將使用表鎖！。
--------這個是針對update沒有索引的情況，行鎖可能升級爲表鎖。
更多隔離跟鎖介紹：https://www.jianshu.com/p/d40dfc904622
3、索引過濾性太差引起CPU飆高分析
有一點是經常被忽略的，那就是索引的過濾性。比如我們給一個整型字段加索引，而這個字段在幾乎所有的記錄上的值都是1（過濾性很差），那麼我們通過這個索引來查找數據就會遍歷大部分無關記錄，造成浪費。
我們知道update語句也是通過索引來查找待更新的數據的，而且update會給索引查找的記錄加上X鎖，因此索引過濾性不好不但造成性能下降，還有可能造成鎖爭奪和鎖等待的損耗。
我們看到耗CPU最高的調用函數棧是…mutex_spin_wait->ut_delay，屬於鎖等待的邏輯。InnoDB在這裏用的是自旋鎖，鎖等待是通過調用ut_delay做空循環實現的，會消耗CPU。
需要重點看一下：http://mysql.taobao.org/monthly/2015/10/03/
4、數據庫技術學習貼（非常值得學習）
阿里月報：http://mysql.taobao.org/monthly/
https://www.cnblogs.com/crazylqy/p/7611069.html