hash索引的限制
hash索引必須進行二次查詢
hash索引無法用於排序
hash索引不支援部分索引查詢，也不支援範圍查詢
hash索引中hash碼的計算可能存在hash衝突
為什麼要使用索引
索引大大減少了儲存引擎需要掃瞄的資料量
索引可以幫助我們進行排序以避免使用臨時表
索引可以把隨機i/o變為順序i/o
索引優化策略
索引列上不能使用表示式或函式
字首索引和索引列的選擇性，索引的選擇性是不重複的索引值和表的記錄數的比值
聯合索引
如何選擇索引列的順序
經常會被使用到的列優先
選擇性高的列優先
寬度小的列優先
覆蓋索引
優點：可以優化快取，減少磁碟io操作
可以減少隨機io，變隨機io操作變為順序io操作
可以避免對innodb主鍵索引的二次查詢
可以避免myisam表進行系統呼叫
無法使用覆蓋索引的情況：
儲存引擎不支援覆蓋索引
查詢中使用了太多的列
使用了雙%號的like查詢
使用索引來優化查詢
使用索引掃瞄來優化排序
通過排序操作
按照索引順序掃瞄資料
索引的列順序和order by子句的順序完全一致
索引中所有列的方向（公升序，降序）和order by子句完全一致
order by中的字段全部在關聯表中的第一張表中
模擬hash索引優化查詢
只能處理鍵值的全值匹配查詢
所使用的hash函式決定著索引鍵的大小
刪除重複和冗餘的索引
查詢未被使用過的索引
更新索引統計資訊及減少索引碎片
analyze table table_name
optimize table table_name 使用不當會導致鎖表
如何獲取由效能問題的sql
通過使用者反饋獲取存在效能問題的sql
通過慢查日誌獲取存在效能問題的sql
實時獲取存在效能問題的sql
使用慢查詢日誌獲取有效能問題的sql
slow_query_log 啟動停止記錄慢查日誌 set global
slow_query_log_file 指定慢查詢日誌的儲存路徑及檔案（日誌儲存和資料儲存分開儲存）
long_query_time 指定記錄慢查日誌sql執行時間的伐值 （記錄所有符合條件的sql）
常用的慢查詢日誌分析工具 （mysqldumpslow）
彙總除查詢條件外其他完全相同的sql，並將分析結果按照引數中所指定的順序輸出
mysqldumpslow -s r -t 10 slow-mysql.log
-s order(c,t,l,t,at,al,ar) 指定按哪種排序方式輸出結果
c ：總次數
t ：總時間
l ：鎖的時間
r ：總資料行
at，al，ar：t，l，r平均數
-t top 指定取前幾條作為結束輸出
常用的慢查日誌分析工具（pt-query-digest）
pt-query-digest \
--explain h=127.0.0.1,u=root,p=p@ssword \
slow-mysql.log
查詢速度為什麼會慢？
客戶端傳送sql語句給伺服器
伺服器檢查是否可以在查詢快取中命中該sql
伺服器端進行sql解析，預處理，再由優化器生成對應的執行計畫
根據執行計畫，呼叫儲存引擎api來查詢資料
將結果返回給客戶端
查詢快取對sql效能的影響
優先檢查這個查詢是否命中查詢快取中的資料
通過乙個對大小寫敏感的雜湊查詢實現的
對於乙個讀寫頻繁的系統使用查詢快取很可能會降低查詢處理的效率
所以在這種情況下建議不要使用查詢快取
query_cache_type 設定查詢快取是否可用
demand 表示只有在查詢語句中使用sql_cache和sql_no_cache來控制是否需要快取
query_cache_size 設定查詢快取的記憶體大小
query_cache_limit 設定查詢快取可用儲存的最大值
加上sql_no_cache可以提高效率
query_cache_wlock_invalidate 設定資料表被鎖後是否返回快取中的資料
query_cache_min_res_unit 設定查詢快取分配的記憶體塊最小單位
mysql 依照這個執行計畫和儲存i 引擎進行互動
這個階段包括了多個子過程：
解析sql，預處理，優化sql執行計畫
語法解析階段是通過關鍵字對mysql語句進行解析，並生成一顆對應的「解析樹」
mysql解析器將使用mysql語法規則驗證和解析查詢
包括檢查語法是否使用了正確的關鍵字
關鍵字的順序是否正確等
預處理階段是根據mysql規則進一步檢查解析樹是否合法
檢查查詢中所涉及的表和資料列是否存在及名字或別名是否存在歧義等等
語法檢查全都通過了，查詢優化器就可以生成查詢計畫了
sql的解析預處理及生成執行計畫
會造成mysql生成錯誤的執行計畫的原因
統計資訊不準確
執行計畫中的成本估算不等同於實際的執行計畫的成本（mysql伺服器層並不知道哪些頁面在記憶體中 哪些頁面在磁碟上 哪些需要順序讀取 哪些要頁面隨機讀取）
mysql優化器所認為的最優可能與你所認為的最優不一樣（基於其成本模型選擇最優的執行計畫）
mysql 不會考慮不受其控制的成本（儲存過程，使用者自定義的函式）
mysql優化器可優化的sql型別
重新定義表的關聯順序（優化器會根據統計資訊來決定表的關聯順序）
將外連線轉化成內鏈結 （where條件和庫表結構等）
使用等價變換規則（5=5 and a>5）將被改寫為a>5
優化count() ,min()和max() (select tables optimized away 優化器已經從執行計畫中移除了該錶，並以乙個常數取而代之)
講乙個表示式轉化為常數表示式
子查詢優化 （子查詢轉換為關聯查詢）
提前終止查詢
對in（）條件進行優化
如何確定查詢處理各個階段所消耗的時間
使用profile
減少查詢所消耗的時間，加快查詢的相應速度
set profiling =1 ；
啟動profile ，這是乙個session級的配置
執行查詢
show profiles; 檢視每乙個查詢所消耗的總時間的資訊
show profile for query n; 查詢的每個階段所消耗的時間
如何確定查詢處理各個階段所消耗的時間
使用performance_schema
update `setup_instruments` set enabled = ' yes',timed='yes' where name like 'stage%';
update setup_consumers set enabled='yes' where name like 'events%';
大表的資料修改最好要分批處理
1000萬行記錄的表中刪除/更新100萬行記錄一次只刪除/更新5000行記錄，暫停幾秒
特定的sql的查詢優化
如何修改大表的表結構
pt-online-schema-change \
--alter = "modify c varchar(150) not null default '' " \
--user=root --password=password d=databasename,t=tablename \
--charset=utf8 --execute
Mysql的索引 效能分析與SQL優化
索引效能分析 sql優化 優化策略 慢查詢日誌 鎖機制b樹 對比項myisam innnodb 主外來鍵不支援 支援事物 不支援支援 行表鎖表鎖，即使操作一條記錄 行鎖快取 只快取索引，不快取真實資料 索引與資料都會快取，堆記憶體要求較高，且記憶體大小對效能有決定性的影響 表空間小 大關注點 效能事...
MySQL高階效能優化 效能分析
是指資料庫表的每一列都是不可分割的基本資料項，同一列不能有多個值。第一正規化 1nf 是對關係模式的基本要求，不滿足第一正規化的資料庫就不是關聯式資料庫 要求資料庫表中的每個例項或行必須可以被唯一的區分。設定主鍵來區分 要求乙個資料庫表中不包括已在其它表中已包含的非主關鍵資訊。兩張表不要重複的字段，...
linux 效能分析與優化
一 影響linux伺服器效能的因素 1 作業系統級 cpu 記憶體 磁碟i o效能 網路頻寬 2 程式應用級 二 系統效能評估標準好 壞 極差cpu user sys 70 user sys 85 user sys 90 記憶體swap in si 0 swap out si 0 per cpu w...