影響mysql server性能的相關因素
需求和架構及業務實現優化：55%
Query語句優化：30%
數據庫自身優化：15%
很多時候大家看到數據庫應用系統中性能瓶頸出現在數據庫方面，就希望通過數據庫的優化來解決問題，但不管DBA對數據庫多么了解，對Query語句的優化多么靜態，最終還是很難解決整個系統的性能問題，原因在於並沒有找到根本的症結所在。
所以數據庫的優化實際上是一個需要多方面配合多方面優化才能根本性改善的事情，可以概括性的歸為：商業需求合理化、系統架構最優化、實現邏輯精簡化、硬件設施理性化。
mysql數據庫鎖定機制
mysql各存儲引使用了三種鎖定機制：行級鎖定、表級鎖定和頁級鎖定。這里主要談一下InnoDB存儲引擎實現的行級鎖定（NDB Cluster也是行級鎖定的存儲引擎）。InnoDB和其他數據庫的行級鎖定機制類似，都有共享鎖S和排他鎖X，為了讓行級鎖定和表級鎖定共存，
InnoDB同樣使用了意向鎖的概念（表級鎖定），就有了意向共享鎖IS和意向排他鎖IX。共享鎖可以共存，但排他鎖不可以，InnoDB和其他數據庫最大的不同是實現行鎖的機制，其他數據庫時通過在需要鎖定的某行記錄所在的物理Block上的事務槽上面添加鎖定信息，而
InnoDB的鎖定是通過指向數據記錄的第一個索引建之前和最后一個索引建之后的空域表級鎖定信息實現行級鎖定，被稱為間隙鎖。間隙鎖有很多弱點：
1.鎖定一個范圍鍵值之后即使某些不存在的鍵值也會被鎖定，這就造成了鎖定范圍內無法插入數據，會對性能帶來影響。
2.當Query無法命中索引的時候，InnoDB會放棄行鎖定而改用表鎖定，造成並發性能降低
眾所周知，行級鎖定會造成死鎖的存在，死鎖產生的原因：
1.不同表，相同的記錄（事務A和事務B操作兩張表的相同記錄，順序不一致）
2.相同表記錄（事務A和事務B操作同一張的表的相同記錄，順序不一致：jobA處理的的id列表為[1,2,3,4]，而job處理的id列表為[8,9,10,4,2]）
3.不同的索引沖突：事務A在執行時，除了在二級索引加鎖外，還會在聚簇索引上加鎖，在聚簇索引上加鎖的順序是[1,4,2,3,5]，而事務B執行時，只在聚簇索引上加鎖，加鎖順序是[1,2,3,4,5]，這樣就造成了死鎖的可能性
InnoDB監測死鎖的機制是選擇較小的事務回滾，標准是衡量插入或者更新刪除數據的多少。
InnoDB行鎖優化建議：
1.盡可能讓所有數據檢索都通過索引來完成，避免升級為表級鎖定
2.合理設計索引，可以縮小行鎖的鎖定范圍，避免造成不必要的鎖定影響其他Query執行
3.盡可能減少基於范圍的數據檢索過濾條件，避免間隙鎖鎖定不該鎖定的記錄
4.控制事務大小，減少鎖定的資源量和鎖定時間長度
5.使用較低級別的事務隔離
減少死鎖建議：
1.盡可能按照相同順序的來訪問資源
2.在同一個事務中盡可能做到一次性鎖定所有資源，減少死鎖的概率
3.對於非常容易產生死鎖的業務部分嘗試升級鎖的粒度，通過表級鎖定來減少死鎖產生的概率
系統鎖定爭用情況查詢：
表級鎖定：SHOW STATUS LIKE 'table%'；Table_locks_immediate(表級鎖定的次數)，Table_locks_waited(表級鎖定爭用次數)
行級鎖定：SHOW STATUS LIKE 'innodb_row_lock%';Innodb_row_lock_current_waits(當前正在鎖定的數量)，Innodb_row_lock_time(從系統啟動到現在鎖定總時間長度)，Innodb_row_lock_time_avg/max(平均時間/最長的一次時間),Innodb_row_lock_waits(等待次數)