序：
即使有較長的快取有效期和較理想的快取命中率，但是快取的建立和快取過期後的重建都是需要訪問資料庫的。對資料庫寫操作不是很容易引入快取策略。
11.1 檢視資料庫狀態
可以通過show status、show innodb status 來檢視mysql資料庫的狀態，使用mysqlreport這個第三方工具可使資料庫狀態報告更好看(mysqlreport本質是通過mysql內部命令和工具來統計狀態的)。
11.2 正確使用索引
在影響資料庫查詢效能的眾多因素中，索引絕對是乙個重量級的因素，如果索引使用不當，則資料庫的其它優化可能無濟於事。
索引是用於快速定位到表記錄所在位址的一種資料結構(btree、hash、rtree等)。通過索引去查詢記錄即為索引掃瞄。
索引掃瞄不一定比全表掃瞄效能更好，要看情況。查詢優化器會為一次查詢是否使用索引以及決定使用哪個索引，當然，有時查詢優化器也會犯錯誤。
資料庫的索引需要定位到每行記錄，所有索引項的數量也會非常多，通過索引列表查詢某索引項也會存在一定的小開銷。
除了普通索引外還有唯一索引、主鍵索引、非空索引、全文索引等，不同的索引只是約束和用途不一樣。像唯一索引在插入資料時就會增加一定的開銷，因為它每插入一次都要判斷是否重複。
一般如果乙個字段出現在查詢語句基於行的選擇、分組和排序，那麼為該字段建立索引可能是有價值的。
explain只可分析查詢語句，不能用於分析更新操作的語句。
在explain中，若type為const，說明查詢可以通過索引直接找到匹配行，key為primary說明使用了主鍵索引。若type為all,說明使用了全表掃瞄，索引未使用上，此時的key 為空。若type為ref，說明查詢的結果可能有多個匹配行。若type為index，說明查詢只需要在索引中掃瞄即可。
一次查詢對乙個資料表只能使用乙個索引，不能進行索引效應疊加。
最左字首是使用組合索引的最基本原則。
非順序的索引型別如hash對order by是無效的。
對於包含group by的查詢，資料庫一般是先將記錄分組後放到臨時表中，然後對其進行函式運算。這時若有恰當索引時，可使用索引來代替臨時表的使用。
可以使用慢查詢配置來記錄查詢慢的語句，也可以記錄未使用索引的查詢語句。
為了節省查詢索引的時間，可以將索引快取起來放到記憶體中，這樣最理想的情況，索引可以直接在記憶體中查詢而不需要訪問磁碟。myisam表包括3個檔案，分別是.frm、.myi、.myd。也即myisam表型別只快取索引不快取資料檔案。由於存在索引寫快取機制，myisam表型別對於索引的寫操作存在延遲。
在使用索引時也要考慮到其代價，索引會佔據更多的磁碟空間，有時甚至比資料檔案還要大。當在建立了索引的字段上進行更新時，其索引也需要更新，這個開銷可不小。索引也需要花時間來維護。
11.3 鎖定與等待
鎖機制是影響查詢效能的另乙個因素，當多個併發使用者同時訪問同一資源時，資料庫為保證併發訪問的一致性，使用資料庫鎖來協調訪問。
查詢時間的開銷包括查詢本身的計算時間和查詢前的等待時間，索引影響的是前者，鎖機制影響的是後者。
mysql為myisam表型別提供的是表鎖。表鎖允許多個執行緒同時讀取資料(select)，但對於更新操作會排斥所有其它的查詢包括select，而且更新操作具有預設的高優先順序。
如果大部分為查詢操作，只有少許更新操作，則不會存在太多的鎖等待。
mysql為innodb表型別提供的是行鎖。行鎖可以帶來update和select不同執行緒對不同的行記錄可以併發地進行。
行鎖並不一定比表鎖快，開銷不一定比表鎖小，尤其是涉及全表掃瞄時行鎖的開銷更大。
11.4 事務性表的效能
innodb除了支援行鎖外，它還支援事務，innodb實現事務的方法是通過預寫日誌的方式。當有事務提交時，innodb將它寫入到記憶體的事務日誌緩衝區中，隨後將事務日誌寫入磁碟，從而更新實際的資料和索引。
事務日誌寫入磁碟的時機：
innodb_flush_log_at_trx_commit=1時，代表事務提交時事務日誌立即寫入磁碟，同時更新資料和索引。
innodb_flush_log_at_trx_commit=0時，代表事務提交時事務日誌不立即寫入磁碟，而是每隔1秒寫入磁碟檔案一次，並重新整理到磁碟同時更新資料和索引。
innodb_flush_log_at_trx_commit=2時，代表事務提交時事務日誌立即寫入磁碟檔案，每隔1秒重新整理到磁碟同時更新資料和索引。
通過以上3種時機可以對比出它們的可靠性和效能。
11.5 使用查詢快取
查詢快取就是將select查詢結果放在記憶體中，key是select語句，value是該查詢語句的結果。不論是myisam還是innodb引擎，查詢快取都可以很好地工作，起到提公升效能的作用。查詢快取要注意快取過期策略，在mysql中，若乙個表中有更新操作，則該錶的所有查詢快取將失效。因此，對於select密集型更新很少的應用很適合使用查詢快取。
11.6 臨時表
在explain查詢語句時，有時可以看到using temporary狀態，這說明查詢過程使用了臨時表來儲存中間資料，可以通過合理使用索引來避免建立臨時表情況。若臨時表的使用不可避免，那麼也應該儘量減少臨時表本身的開銷。
mysql的臨時表可以建立在磁碟、記憶體和臨時檔案中。當然，建立在磁碟上的開銷最大。有時在使用show processlist可以看到查詢狀態中有coping to tmp table on disk，這說明mysql在將臨時表從記憶體中複製到磁碟上以節省記憶體空間。
可以通過tmp_table_size選項來設定用於儲存臨時表的記憶體空間大小。一旦空間不夠用才會使用磁碟來儲存。
11.7 執行緒池
mysql使用多執行緒來處理併發連線。為減少重複執行緒的建立可以盡量使用持久連線或將連線快取起來(通過在my.cnf中配置thread_table_size=個數來設定)。
11.8 反正規化設計
所謂正規化就是對關聯式資料庫中的關係的要求或約束，有不同程式的要求就有不同的正規化。通常遵循到3nf即可，3nf就是非主鍵字段之間不能存在依賴關係，這樣可以避免刪除、更新、插入異常，保持關係的一致性，減少資料冗餘。
反正規化化就是違背關係設計的要求或約束，用於減少讀取資料的開銷，增加一定的資料冗餘，但這樣同時也增加了寫資料的開銷，因為要保持冗餘資料的一致性。當然，為了保證資料庫寫效能可以非同步寫資料。若不想反正規化則可以使用非關係型資料庫。
11.9 使用非關聯式資料庫
key-value資料庫使用半結構化儲存資料，所有資料只有乙個索引即key，可以將反正規化化引發的資料副本儲存到key-value資料庫中，這樣比關聯式資料庫具有更出色的併發效能。
memcachedb在效能方面比較出色，是乙個分布式的key-value資料庫，使用memcache協議，這意味著使用了memcache的web應用可以不進行任何的修改而遷移到memcachedb上。
不是所有的應用都適合用key-value資料庫，該用關係查詢的時候還是得用關聯式資料庫，key-value資料庫只是為避免反正規化化引發的寫資料開銷方案之一。當然，memcachedb封裝了berkeley db的複製功能，可以通過主從複製來擴充套件memcachedb的規模，提公升可用性。
效能優化 MySQL資料庫優化
可以從哪幾個方面進行資料庫的優化？如下圖所示 a sql及索引優化 根據需求寫出良好的sql，並建立有效的索引，實現某一種需求可以多種寫法，這時候我們就要選擇一種效率最高的寫法。這個時候就要了解sql優化 b 資料庫表結構優化 根據資料庫的正規化，設計表結構，表結構設計的好直接關係到寫sql語句。c...
效能優化 mysql資料庫
一 mysql常用命令 1.開啟日誌 1 show global variables like genera 2 set global general log on 3 set global general log off 2.mysql如果開了set autocommit 0，那麼所有的語句一定是...
優化MySQL資料庫效能
mysql資料庫的速度快慢是需要配置優化的，如果是我們自己用，比如幾個人的時候，人數較少就算優化了也看不出什麼效果來，如果人數非常多的時候就會看出來了，下面介紹十個比較重要的引數配置，max connections，record buffer，back log，interactive timeout...