mysql的存儲優化

⑴ Mysql內存使用以及優化中需要的幾點注意

1、從內存中讀取數據是微秒級別的。而從磁碟讀則是毫秒級別的。二者相差一個數量級。所以想優化資料庫，第一個要做到的就是優化io。
2、key_buffer_size[global]設置的內存區域大小緩存了myisam表的索引。由於myisam只緩存索引在內存中，並不緩存數據在內存，所以如果內存允許，要讓這個參數足夠能容納所有myisam的所有索引來提高性能。另外，在myisam表上，盡量讓所有的查詢條件都限制在索引上，以便能讓緩存替我們提高查找效率。
3、bulk_insert_buffer_size[thread]僅僅用在myisam中，用於在插入數據的時候臨時緩存數據。當我們使用如下的寫入語句的時候，會使用這個內存區域幫助批量寫入數據文件：
insert ... select ...
insert into ... values ...

⑵ mysql存儲過程的if判斷有多個條件該怎麼優化效率

這個應該不會太慢吧，我建議你看一下，你是不是循環做了太多次的插入/更新操作。
mysql默認的配置中，每次事務提交都要寫binlog和redo log，如果循環太多次——比如循環插入10w條記錄——就會非常慢。一般優化思路分兩種：
1 修改 sync_binlog為一個100-1000間的值，讓binlog每隔100-1000個事務後再寫一次；修改innodb_flush_log_at_trx_commit =2； 這么搞的好處是降低了寫log的次數和消耗的時間，缺點是，中間出錯的話，會丟失一部分的binlog和redolog導致無法通過他們來在出問題是恢復生產庫數據。
2 將所有的插入/更新操作放到一個事務中進行。這樣，顯然就只需要一次寫binlong和redolog咯。

⑶ mysql資料庫的優化方法

我們都知道，伺服器資料庫的開發一般都是通過java或者是PHP語言來編程實現的，而為了提高我們資料庫的運行速度和效率，資料庫優化也成為了我們每日的工作重點，今天，霍營IT培訓就一起來了解一下mysql伺服器資料庫的優化方法。

為什麼磨局要了解索引

真實案例

案例一：大學有段時間學習爬蟲，爬取了知乎300w用戶答題數據，存儲到mysql數據中。那時不了解索引，一條簡單的「根據用戶名搜索全部回答的sql「需要執行半分鍾左右，完全滿足不了正常的使用。

案例二：近線上應用的資料庫頻頻出現多條慢sql風險提示，而工作以來，對資料庫優化方面所知甚少。例如一個用戶數據頁面需要執行很多次資料庫查詢，性能很慢，通過增加超時時間勉強可以訪問，但是性能上需要優化。

索引的優點

合適的索引，可以大大減小mysql伺服器掃描的數據量，避免內存排序和臨時表，提高兄稿應用程序的查詢性能。

索引的類型

mysql數據中有多種索引類型，primarykey，unique，normal，但瞎塵讓底層存儲的數據結構都是BTREE;有些存儲引擎還提供hash索引，全文索引。

BTREE是常見的優化要面對的索引結構，都是基於BTREE的討論。

B-TREE

查詢數據簡單暴力的方式是遍歷所有記錄;如果數據不重復，就可以通過組織成一顆排序二叉樹，通過二分查找演算法來查詢，大大提高查詢性能。而BTREE是一種更強大的排序樹，支持多個分支，高度更低，數據的插入、刪除、更新更快。

現代資料庫的索引文件和文件系統的文件塊都被組織成BTREE。

btree的每個節點都包含有key，data和只想子節點指針。

btree有度的概念d>=1。假設btree的度為d，則每個內部節點可以有n=[d+1，2d+1)個key，n+1個子節點指針。樹的大高度為h=Logb[(N+1)/2]。

索引和文件系統中，B-TREE的節點常設計成接近一個內存頁大小(也是磁碟扇區大小)，且樹的度非常大。這樣磁碟I/O的次數，就等於樹的高度h。假設b=100，一百萬個節點的樹，h將只有3層。即，只有3次磁碟I/O就可以查找完畢，性能非常高。

索引查詢

建立索引後，合適的查詢語句才能大發揮索引的優勢。

另外，由於查詢優化器可以解析客戶端的sql語句，會調整sql的查詢語句的條件順序去匹配合適的索引。