一，索引
1.innodb索引使用的是b+樹
2.盡量簡化where條件，比如不要出現 where id + 3 = 5,這無法使用索引
3.索引很大時，可以冗餘一列來模擬雜湊索引
4.小的表不需要使用索引，很大的表需要用分塊技術，也不用索引
5.索引的選擇性=不重複的數量/總的數量
選擇性越高，效率越高，unique索引選擇性為1，效率最好
對於blob，text，很長的varchar型別的列，必須使用字首索引。
訣竅在於，要選擇足夠長的字首以保證較高的選擇性，同時又不能太長
建立字首索引：(city列裡長度為7的字首索引)
alter table sakila.city_demo add key(city(7))
字首索引的缺點，無法做order by和group by
字尾索引：mysql不支援反向索引，但可以把字串反轉後儲存，並基於此建立索引，可以通過觸發器來維護索引
6、多列索引
對多個列做相交操作（and）時，需要的時乙個多列索引而不是多個單獨的單列索引
如果在explain中看到有索引合併，應該好好檢查一下查詢和表單結構，
可以通過引數optimizer_switch來關閉索引合併
7.覆蓋索引
如果乙個索引包含所有需要查詢的字段的值，我們就稱之為覆蓋索引
由於myisam在記憶體中只存索引，所以用覆蓋索引有嚴重的效能問題
由於innodb的聚簇索引，覆蓋索引對innodb特別有用
另外，只能用b-tree索引做全文索引
當使用覆蓋索引時，explain 中的extra中顯示using index
查詢優化
一般的優化方法有兩個
1.確認應用程式是否在檢索大量超過需要的資料，這通常意味著訪問了太多的行
但有時候也可能是訪問了太多的列
2.確認mysql伺服器層是否在分析大量超過需要的資料行
解決方法，加limit，
如果資料庫資源緊張，可以考慮用mybatis代替hibernate
取出全部列，會讓優化器無法完成覆蓋索引掃瞄這類優化，比如hibernate
不過獲取所有列的查詢快取，比多個獨立的只獲取部分列的查詢快取更有好處
每次看到select * 請去懷疑一下是否真的需要全部取出
重複查詢相同的資料：請把這個資料快取起來，比如放到session中
最簡單的衡量查詢開銷的三個指標：
響應時間，
掃瞄的行數
返回的行數
這三個指標都會記錄到mysql的慢日誌中，所以檢查慢日誌
如果發現查詢需要掃瞄大量的資料行，但返回少量的行，那麼可以嘗試下面的技巧去優化它
1，使用索引覆蓋掃瞄，把所有需要用的列都放到索引中
2.改變表結構，例如使用單獨的彙總表
3.重寫這個查詢，各種優化
有時可以考慮將乙個複雜查詢分為多個小查詢，如果能減少工作量的話
比如刪除舊的資料，每次刪一點，可以避免一次鎖住很多資料
分解關聯查詢的好處
1、快取效率更高
2、用返回的資料的id來進行順序查詢比用join進行隨機關聯效率更高
壞處：一條語句分多條，增加連線開銷
排序優化
無論如何，排序都是乙個成本很高的操作，所以從效能角度考慮，盡可能避免排序，或避免對大量資料進行排序
mysql效能優化 mysql效能優化
優化方式 1.空間換時間 冗餘 2.時間換空間 字段優先使用型別 int date char varchar text 索引型別 btree索引 hash索引 索引的葉子下，存放乙個資訊指向所在行的資料位址。btree有利於範圍查詢，hash有利於精確查詢。btree用的更多一些。btree索引的常...
高效能Mysql筆記 優化
了解查詢的整個生命週期，清楚每個階段的時間消耗情況 參考select profiling 檢視profiling是否開啟 set profiling 1 開啟profiling show profiles 檢視每條查詢的效能 show profile for query id 檢視query id的...
mysql的效能優化 mysql效能優化
檢視安裝指令碼 select version 非互動式超時時間，如jdbc show global variables like wait timeout 互動式超時時間，如資料庫工具 show global variables like interactive timeout show sessi...