【數據庫】MySQL鎖機制、熱備、分表

時間 2019-12-20

標籤數據庫 mysql 機制分表欄目 SQL 简体版

原文原文鏈接

歡迎關注公衆號：【 愛編碼】
若是有須要後臺回覆 2019贈送 1T的學習資料哦！！

注：本文大都來自互聯網，文字較多，基本是概念，若想深刻了解，還需各位本身找文章研究。html

表鎖和行鎖機制

表鎖（MyISAM和InnoDB）

表鎖的優點：開銷小；加鎖快；無死鎖
表鎖的劣勢：鎖粒度大，發生鎖衝突的機率高，併發處理能力低
加鎖的方式：自動加鎖。查詢操做（SELECT），會自動給涉及的全部表加讀鎖，更新操做（UPDATE、DELETE、INSERT），會自動給涉及的表加寫鎖。也能夠顯示加鎖：前端

共享讀鎖：lock table tableName read;
獨佔寫鎖：lock table tableName write;
批量解鎖：unlock tables;

什麼場景下用表鎖

InnoDB默認採用行鎖，在未使用索引字段查詢時升級爲表鎖。
即使你在條件中使用了索引字段，MySQL會根據自身的執行計劃，考慮是否使用索引(因此explain命令中會有possible_key 和 key)。
若是MySQL認爲全表掃描效率更高，它就不會使用索引，這種狀況下InnoDB將使用表鎖，而不是行鎖。所以，在分析鎖衝突時，別忘了檢查SQL的執行計劃，以確認是否真正使用了索引。mysql

第一種狀況：全表更新。事務須要更新大部分或所有數據，且表又比較大。若使用行鎖，會致使事務執行效率低，從而可能形成其餘事務長時間鎖等待和更多的鎖衝突。git

第二種狀況：多表查詢。事務涉及多個表，比較複雜的關聯查詢，極可能引發死鎖，形成大量事務回滾。這種狀況若能一次性鎖定事務涉及的表，從而能夠避免死鎖、減小數據庫因事務回滾帶來的開銷。github

行鎖（InnoDB的行鎖）

行鎖的劣勢：開銷大；加鎖慢；會出現死鎖
行鎖的優點：鎖的粒度小，發生鎖衝突的機率低；處理併發的能力強
加鎖的方式：自動加鎖。對於UPDATE、DELETE和INSERT語句，InnoDB會自動給涉及數據集加排他鎖；對於普通SELECT語句，InnoDB不會加任何鎖；固然咱們也能夠顯示的加鎖：sql

共享鎖：select * from tableName where … + lock in share more
排他鎖：select * from tableName where … + for update

行鎖優化

1 儘量讓全部數據檢索都經過索引來完成，避免無索引行或索引失效致使行鎖升級爲表鎖。
2 儘量避免間隙鎖帶來的性能降低，減小或使用合理的檢索範圍。
3 儘量減小事務的粒度，好比控制事務大小，而從減小鎖定資源量和時間長度，從而減小鎖的競爭等，提供性能。
4 儘量低級別事務隔離，隔離級別越高，併發的處理能力越低。數據庫

InnoDB和MyISAM的最大不一樣點有兩個：
一，InnoDB支持事務(transaction)；
二，默認採用行級鎖。加鎖能夠保證事務的一致性，可謂是有人(鎖)的地方，就有江湖(事務)；咱們先簡單瞭解一下事務知識。後端

MySQL 事務

事務是由一組SQL語句組成的邏輯處理單元，事務具備ACID屬性。
原子性（Atomicity）：事務是一個原子操做單元。在當時原子是不可分割的最小元素，其對數據的修改，要麼所有成功，要麼所有都不成功。
一致性（Consistent）：事務開始到結束的時間段內，數據都必須保持一致狀態。
隔離性（Isolation）：數據庫系統提供必定的隔離機制，保證事務在不受外部併發操做影響的」獨立」環境執行。
持久性（Durable）：事務完成後，它對於數據的修改是永久性的，即便出現系統故障也可以保持。服務器

事務隔離級別

髒讀，不可重複讀，幻讀，其實都是數據庫讀一致性問題，必須由數據庫提供必定的事務隔離機制來解決。架構

雙機熱備

概念

雙機熱備
雙機熱備特指基於高可用系統中的兩臺服務器的熱備（或高可用），因兩機高可用在國內使用較多，故得名雙機熱備。
從廣義上講，就是對於重要的服務，使用兩臺服務器，互相備份，共同執行同一服務。當一臺服務器出現故障時，能夠由另外一臺服務器承擔服務任務，從而在不須要人工干預的狀況下，自動保證系統能持續提供服務。

雙機熱備和備份的區別
熱備份指的是：High Available（HA）即高可用，而備份指的是Backup,即數據備份的一種，這是兩種不一樣的概念，應對的產品也是兩種功能上徹底不一樣的產品。熱備份主要保障業務的連續性，實現的方法是故障點的轉移。而備份，主要目的是爲了防止數據丟失，而作的一份拷貝，因此備份強調的是數據恢復而不是應用的故障轉移。

雙機熱備分類

按工做中的切換方式分爲：
主-備方式（Active-Standby方式）和雙主機方式（Active-Active方式）。

主-備方式即指的是一臺服務器處於某種業務的激活狀態（即Active狀態），另外一臺服務器處於該業務的備用狀態（即Standby狀態)。
雙主機方式即指兩種不一樣業務分別在兩臺服務器上互爲主備狀態（即Active-Standby和Standby-Active狀態）。

mysql 雙機熱備工做原理

簡單的說就是把一個服務器上執行過的sql語句在別的服務器上也重複執行一遍，這樣只要兩個數據庫的初態是同樣的，那麼它們就能一直同步。
固然這種複製和重複都是mysql自動實現的，咱們只須要配置便可。
咱們進一步詳細介紹原理的細節，這有一張圖：

上圖中有兩個服務器，演示了從一個主服務器（master）把數據同步到從服務器（slave）的過程。
這是一個主-從複製的例子。主-主互相複製只是把上面的例子反過來再作一遍。因此咱們以這個例子介紹原理。
對於一個mysql服務器，通常有兩個線程來負責複製和被複制。當開啓複製以後。

1. 做爲主服務器Master，會把本身的每一次改動都記錄到二進制日誌 Binarylog 中。（從服務器會負責來讀取這個log，而後在本身那裏再執行一遍。）
2. 做爲從服務器Slave，會用master上的帳號登錄到 master上，讀取master的Binarylog, 寫入到本身的中繼日誌 Relaylog，而後本身的sql線程會負責讀取這個中繼日誌，並執行一遍。到這裏主服務器上的更改就同步到從服務器上了。

在mysql上能夠查看當前服務器的主，從狀態。其實就是當前服務器的 Binary（做爲主服務器角色）狀態和位置。以及其RelayLog（做爲從服務器）的複製進度。

mysql 雙機熱備實現

參考下面各位大神的配置吧，他們寫得太好了，太詳細了。我就收藏一下。
https://yunnick.iteye.com/blo...
https://www.cnblogs.com/shuid...
https://www.cnblogs.com/fnlin...

分庫分表

基本思想就要把一個數據庫切分紅多個部分放到不一樣的數據庫(server)上，從而緩解單一數據庫的性能問題。

爲何要分庫分表

當一張表的數據達到幾千萬時，你查詢一次所花的時間會變多，若是有聯合查詢的話，我想有可能會死在那兒了。分表的目的就在於此，減少數據庫的負擔，縮短查詢時間。

垂直切分和水平切分

垂直切分

一個數據庫由不少表的構成，每一個表對應着不一樣的業務，垂直切分是指按照業務將表進行分類，分佈到不一樣的數據庫上面，這樣也就將數據或者說壓力分擔到不一樣的庫上面

優勢：

1. 拆分後業務清晰，拆分規則明確。
    2. 系統之間整合或擴展容易。
    3. 數據維護簡單。

缺點：

1. 部分業務表沒法join，只能經過接口方式解決，提升了系統複雜度。
    2. 受每種業務不一樣的限制存在單庫性能瓶頸，不易數據擴展跟性能提升。
    3. 事務處理複雜。

水平切分

相對於垂直拆分的區別是：垂直拆分是把不一樣的表拆到不一樣的數據庫中，而水平拆分是把同一個表拆到不一樣的數據庫中。

優勢：

1. 不存在單庫大數據，高併發的性能瓶頸。
    2. 對應用透明，應用端改造較少。     
    3. 按照合理拆分規則拆分，join操做基本避免跨庫。
    4. 提升了系統的穩定性跟負載能力。

缺點：

1. 拆分規則難以抽象。
    2. 分片事務一致性難以解決。
    3. 數據屢次擴展難度跟維護量極大。
    4. 跨庫join性能較差。

小結

兩張方式共同缺點

1. 引入分佈式事務的問題。
    2. 跨節點Join 的問題。
    3. 跨節點合併排序分頁問題。

目前主要有兩種思路：

A. **客戶端模式**，在每一個應用程序模塊中配置管理本身須要的一個（或者多個）數據源，直接訪問各個 數據庫，在模塊內完成數據的整合。 
    優勢：相對簡單，無性能損耗。   
    缺點：不夠通用，數據庫鏈接的處理複雜，對業務不夠透明，處理複雜。
   B. 經過**中間代理層**來統一管理全部的數據源，後端數據庫集羣對前端應用程序透明；   
    優勢：通用，對應用透明，改造少。   
    缺點：實現難度大，有二次轉發性能損失