由於壓力測試，每個大場景都有3個不同併發級別的小場景，但是在分析awr報告時發現，其中sql執行次數部分並沒有明顯的變化，100併發sql執行次數30000，200併發sql執行次數30000多，根據以往的壓測經驗來看，這肯定是有問題的，但是問題在哪呢？作為測試多年的小明無從著手。請dba看吧，看他那個嫌棄和厭煩的表情就知道要吃閉門羹。
我們自己不能定位麼？現在就開始了解下，需要學習那些，鎖，索引，演算法定位 優化等。先從基礎開始
1、資料索引的儲存是有序的
2、在有序的情況下，通過索引查詢乙個資料是無需遍歷索引記錄的
3、極端情況下，資料索引的查詢效率為二分法查詢效率，趨近於 log2(n)
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欄位建索引一般不會提高資料庫的查詢速度。
1、key 是資料庫的物理結構，它包含兩層意義和作用，一是約束（偏重於約束和規範資料庫的結構完整性），二是索引（輔助查詢用的）。包括primary key, unique key, foreign key 等
2、index是資料庫的物理結構，它只是輔助查詢的，它建立時會在另外的表空間（mysql中的innodb表空間）以乙個類似目錄的結構儲存。索引要分類的話，分為字首索引、全文本索引等；
b+樹索引
雜湊索引
就是採用一定的雜湊演算法，把鍵值換算成新的雜湊值，檢索時不需要類似b+樹那樣從根節點到葉子節點逐級查詢，只需一次雜湊演算法即可,是無序的
如下圖所示：
等值查詢
雜湊索引具有絕對優勢（前提是：沒有大量重複鍵值，如果大量重複鍵值時，雜湊索引的效率很低，因為存在所謂的雜湊碰撞問題。）
如果儲存的資料重複度很低（也就是說基數很大），對該列資料以等值查詢為主，沒有範圍查詢、沒有排序的時候，特別適合採用雜湊索引，例如這種sql：
# 僅等值查詢
select id, name from table where name='李明';
如果乙個表幾乎大部分都在緩衝池中，那麼建立乙個雜湊索引能夠加快等值查詢。
通常情況下
b+樹索引結構適用於絕大多數場景，像下面這種場景用雜湊索引才更有優勢：
innodb 引擎中預設使用的是b+樹索引，
特別注意：
在負載高的情況下，自適應雜湊索引中新增的read/write鎖也會帶來競爭，比如高併發的join操作。like操作和%的萬用字元操作也不適用於自適應雜湊索引，可能要關閉自適應雜湊索引。
MySQL之基本常識
本文章 於 請star 強力支援，你的支援，就是我的動力。toc 優點 缺點 第一正規化 1nf 資料庫表中的字段都是單一屬性的，不可再分。這個單一屬性由基本型別構成，包括整型 實數 字元型 邏輯型 日期型等。第二正規化 2nf 資料庫表中不存在非關鍵字段對任一候選關鍵字段的部分函式依賴 部分函式依...
mysql基本常識
首層連線處理 授權認證和安全等。第二層架構包含mysql核心服務。包括查詢解析 分析 優化 快取以及所有的內建函式 例如 日期 時間 數學和加密函式 所有的跨儲存引擎的功能都在這一層完成，比如儲存過程 觸發器 檢視等。第三層包含了儲存引擎。儲存引擎負責mysql的儲存與提取。伺服器通過api與儲存引...
web 基本常識 1 快取
型別 快取時間 大小備註 cookie 4k1.會與請求 每次傳遞到服務端，2，不同瀏覽器都是有區別的哦 localstorage 一直都在 持久化 5m就在瀏覽器裡 sessionstorage 在會話階段 5m就在瀏覽器裡 咋說呢 花錢買的cdn 又有專門的文件 感覺咋說 都是配置 當然 說到c...