mysql 效能優化點記錄
第一章myisam，可以基於blob和text的前500位元組，建立索引
myisam 支援fulltext
延遲更新索引
(delay_key_write)
create table `table3` (
`id` int(11) not null auto_increment,
`name` varchar(30) default null,
`id2` int(11) default null,
primary key (`id`)
) engine=myisam default charset=utf8 delay_key_write = 1
alter table table2 delay_key_write = 1
只有myisam支援全文檢索
第三章 索引方面
字段盡可能的小
盡量避免null，用0代替。但是對效能的提公升很小，最後考慮，索引的列最好不適用null
mysql效能優化點記錄
一、優化資料訪問
查詢效能低下的最基本原因就是訪問了太多資料。一些查詢不可避免的要篩選大量的資料，單這並不常見。大部分效能欠佳的查詢都可以用減
少資料訪問的方式進行修改。在分析效能欠佳的查詢的時候，下面兩個步驟比較有用：
1.應用程式是否在獲取超過需要的資料。這通常是訪問了過多的行或列。
2.mysql伺服器是否分析了超過需要的行。
對於訪問的資料行很大，而生成的結果中資料行很少，可以嘗試修改。
1.使用覆蓋索引，它儲存了資料，所以儲存引擎不會去完整的行。
2.更改架構，乙個例子就是使用彙總表。
3.重寫複雜的查詢，讓mysql的優化器可以優化的執行。
二、複雜查詢和多個查詢
1.把乙個複雜的查詢分解為多個簡單的查詢。（mysql一般的伺服器，每秒鐘可以處理50 000個查詢）
2.三、縮短查詢
將一次處理大量資料的操作，分解為多個小操作。迴圈的方式每次處理一部分資料。一次刪除不要超過10 000行（delete）
四、分解鏈結
把乙個多表連線分解成多個單個查詢，然後在應用程式裡實現聯接。
這樣的優勢
1.快取效率高。
2.mysql，可以更有效的利用表鎖，查詢會鎖住單個表較短時間。
3.應用程式進行聯接可以更方便的拓展資料庫，把不同表放在不同伺服器上。
4.查詢更高效。
5.可以減少多餘的行訪問，可以減少網路流量和記憶體消耗。
小結：在程式端進行聯接的效率更高
1.可以快取早期查詢的大量資料。
2.使用了多個myisam表
3.資料分布在不同的伺服器上。
4.對於大表使用in替換聯接
5.乙個連線引用了同乙個表多次。
當你重建彙總和快取表的時候，在操作的時候你常常需要它們的資料保持可見。你可以使用「shadow table」（影像表）來實現。當你已經建立它之後，你可以使用原子性的重新命名來交換這些表。舉個例子，如果
你需要重建my_summary，你能建立my_summary_new，填充資料，把它和真正的表作交換。
mysql> drop table if exists my_summary_new, my_summary_old;
mysql> create table my_summary_new like my_summary;
-- populate my_summary_new as desired
mysql> rename table my_summary to my_summary_old, my_summary_new to my_summary;
mysql執行查詢的一般性過程
1.客戶端傳送查詢到伺服器
2.伺服器檢查查詢快取，
3.伺服器解析，預處理和優化查詢，生成執行計畫。
4.執行引擎呼叫儲存引擎api執行查詢。
5.伺服器將結果傳送到客戶端。
mysql客戶端、伺服器協議
1.協議是半雙工的。mysql伺服器在某個時間可以傳送或者接受資料，單不能同時傳送和接收。所有沒有辦法階段訊息。
2.客戶端用乙個資料報將查詢傳送到伺服器，所以max_packet_size這個配置引數對於大查詢很重要的原因。
3.客戶端從伺服器提取資料的時候是伺服器產生資料的同時把它們「推」到客戶端的，客戶端只需要接收推出來的資料，無法告訴伺服器停止
傳送資料。
查詢快取
select sql_no_cache * from ol_answerlog limit 1000
show status like 'last_query_cost'
關鍵字straight_join 強制執行引擎按照查詢中表現的順序來進行鏈結操作。
嚴格的說，mysql不回嘗試減少讀取的行數，它只會試著優化對頁面的讀取，但是行數可以大致顯示查詢的開銷。
連線優化器試著產生最低開銷的查詢計畫。在可能的時候，他會從單錶計畫開始，檢查所有的可能的子樹的組合。但是對n個表連線，需要檢
查組合的數量就是n的階乘，這個數量稱為ie搜尋空間， 它增長非常快，如果乙個查詢需要連線10個表，那麼要檢查的數量將是10！=36288000
當搜尋空間非常巨大的時候優化耗費的時間就會非常長，這時候伺服器就不回執行完整的分析，但表的數量超過optimizer_search_depth的值
時，它就會走捷徑，比如執行所謂的 貪婪搜尋。
show table status from `servant_591up`where engine is not null
and name like '%ol_ans%';
max min的優化
select min(id) from ol_user where username = '[email protected]'
Mysql效能優化點
全值匹配我最愛 最佳左字首法則如果索引了多列，要遵守最左字首法則。具體是指，查詢的where條件從索引的最左前列開始並且不跳過索引的中間列 不在索引列上做任何操作 計算 函式 自動or手動 型別轉換 會導致索引失效 儲存引擎不能使用索引中範圍條件右邊的列 盡量使用覆蓋索引 索引列和查詢列一致 減少s...
C 專案效能優化點 記錄
最近入職新公司，要做乙個高效能的專案，對比之前公司的 確實有一些細節是能夠提公升效能的，所以記錄一下，發現一點就記錄一點 不侷限於公司專案中用到的，其它地方看到的也會記錄 持續更新 define likely x builtin expect x 1 x很可能為真 define unlikely x...
mysql效能優化 mysql效能優化
優化方式 1.空間換時間 冗餘 2.時間換空間 字段優先使用型別 int date char varchar text 索引型別 btree索引 hash索引 索引的葉子下，存放乙個資訊指向所在行的資料位址。btree有利於範圍查詢，hash有利於精確查詢。btree用的更多一些。btree索引的常...