由於壓力測試，每個大場景都有3個不同併發級別的小場景，但是在分析AWR報告時發現，其中SQL執行次數部分並沒有明顯的變化，100併發SQL執行次數30000，200併發SQL執行次數30000多，根據以往的壓測經驗來看，這肯定是有問題的，但是問題在哪呢？作爲測試多年的小明無從着手。請DBA看吧，看他那個嫌棄和厭煩的表情就知道要吃閉門羹。
我們自己不能定位麼？現在就開始瞭解下，需要學習那些，鎖，索引，算法定位 優化等。先從基礎開始
基本概念篇
通常我們在性能測試中，60%的性能瓶頸存在於數據環節，數據環節的一半性能問題又是在SQL。
一、爲什麼使用數據索引能提高效率？
1、數據索引的存儲是有序的
2、在有序的情況下，通過索引查詢一個數據是無需遍歷索引記錄的
3、極端情況下，數據索引的查詢效率爲二分法查詢效率，趨近於 log2(N)
二、關於 MySQL 聯合索引
1、聯合索引是兩個或更多個列上的索引。
對於聯合索引:Mysql從左到右的使用索引中的字段，一個查詢可以只使用索引中的一部份，但只能是最左側部分。
例如索引是key index (a,b,c). 可以支持a 、 a,b 、 a,b,c 3種組合進行查找，但不支持 b,c進行查找 .當最左側字段是常量引用時，索引就十分有效。
2、利用索引中的附加列，您可以縮小搜索的範圍，但使用一個具有兩列的索引不同於使用兩個單獨的索引。
複合索引的結構與電話簿類似，人名由姓和名構成，電話簿首先按姓氏對進行排序，然後按名字對有相同姓氏的人進行排序。
如果您知道姓，電話簿將非常有用；如果您知道姓和名，電話簿則更爲有用，但如果您只知道名不知道姓，電話簿將沒有用處。
那麼什麼情況下不建或少建索引？
1、表記錄太少
2、行爲表 -如訂單表
數據重複且分佈平均的表字段，假如一個表有10萬行記錄，有一個字段A只有T和F兩種值，且每個值的分佈概率大約爲50%，那麼對這種表A字段建索引一般不會提高數據庫的查詢速度。
三、key和index的區別
1、key 是數據庫的物理結構，它包含兩層意義和作用，一是約束（偏重於約束和規範數據庫的結構完整性），二是索引（輔助查詢用的）。包括primary key, unique key, foreign key 等
2、index是數據庫的物理結構，它只是輔助查詢的，它創建時會在另外的表空間（mysql中的innodb表空間）以一個類似目錄的結構存儲。索引要分類的話，分爲前綴索引、全文本索引等；
四、B+樹索引和哈希索引的區別？
B+樹索引
B+樹是一個平衡的多叉樹，從根節點到每個葉子節點的高度差值不超過1，而且同層級的節點間有指針相互鏈接，是有序的，如下圖：
哈希索引
就是採用一定的哈希算法，把鍵值換算成新的哈希值，檢索時不需要類似B+樹那樣從根節點到葉子節點逐級查找，只需一次哈希算法即可,是無序的
如下圖所示：
二、哪個更好呢？
等值查詢
哈希索引具有絕對優勢（前提是：沒有大量重複鍵值，如果大量重複鍵值時，哈希索引的效率很低，因爲存在所謂的哈希碰撞問題。）
如果存儲的數據重複度很低（也就是說基數很大），對該列數據以等值查詢爲主，沒有範圍查詢、沒有排序的時候，特別適合採用哈希索引，例如這種SQL：
# 僅等值查詢
select id, name from table where name='李明';
如果一個表幾乎大部分都在緩衝池中，那麼建立一個哈希索引能夠加快等值查詢。
通常情況下
B+樹索引結構適用於絕大多數場景，像下面這種場景用哈希索引才更有優勢：
InnoDB 引擎中默認使用的是B+樹索引，
特別注意：
在負載高的情況下，自適應哈希索引中添加的read/write鎖也會帶來競爭，比如高併發的join操作。like操作和%的通配符操作也不適用於自適應哈希索引，可能要關閉自適應哈希索引。