MySQL地基

數據庫系統工做原理：

    1. 用戶向數據庫發起鏈接；

    2. MySQL數據庫驗證權限。若是權限不夠，直接拒絕 ，權限ok進入下一步；

    3. 用戶開始發起SQL語句；

    4. MySQL數據庫解析器開始解析SQL語句；

    5. MySQL開始查詢本身的本地緩存，有的話直接反饋給用戶，沒有的話，進入下一步；

    6. 通過解析器。對SQL語句進行定位，最後找到所須要的數據，在本地緩存一份，而後反饋給用戶。

---

MySQL數據庫引擎：

     1. innoDB 優點：提供了良好的事物管理、崩潰、修復能力和併發控制

         缺點：讀寫效率稍差，佔用的數據空間相對比較大

            使用場合：在承載的大部分項目執行insert和update的話，應選擇InnoDB

2. MyISAM 優點：佔用空間小，處理速度快

          缺點：不支持事務日誌的完整性和併發性

                使用場合:在承載的大部分項目是讀多寫少的項目平臺中，而myISAM的讀寫性能是比InnoDB強很多的

   3. MEMORY 優點：存儲速度快

          缺點：缺少穩定性和完整性

---

事務具備四個特性：原子性（atomiocity） 一致性（consistency）隔離性（Isolation） 持久性（Durability）   簡稱爲ACID特性

通俗的說事務: 指一組操做,要麼都成功執行,要麼都不執行.---->原子性

在全部的操做沒有執行完畢以前,其餘會話不可以看到中間改變的過程-->隔離性

事務發生前,和發生後,數據的總額依然匹配----->一致性

事務產生的影響不可以撤消------>持久性

若是出了錯誤,事務也不容許撤消, 只能經過"補償性事務"。

---

mysql常見的三種鎖級別——表級鎖、頁面鎖、行級鎖；其中表級鎖有兩種模式——表共享讀鎖和表獨佔寫鎖。

行級鎖的優勢以下：

1.當不少鏈接分別進行不一樣的查詢時減少LOCK狀態。

2.若是出現異常，能夠減小數據的丟失。由於一次能夠只回滾一行或者幾行少許的數據。

行級鎖的缺點以下：

1.佔用更多的內存。

2.須要的I/O更多，因此咱們常常把行級鎖用在寫操做而不是讀操做。

3.容易出現死鎖。

---

Mysql複製的幾種模式：

1. 基於sql語句的複製

2. 基於行的複製

3. 混合模式複製 

異步複製（Asynchronous replication）

    MySQL默認的複製便是異步的，主庫在執行完客戶端提交的事務後會當即將結果返給給客戶端，並不關心從庫是否已經接收並處理，這樣就會有一個問題，主若是crash掉了，此時主上已經提交的事務可能並無傳到從上，若是此時，強行將從提高爲主，可能致使新主上的數據不完整。

全同步複製（Fully synchronous replication）

    指當主庫執行完一個事務，全部的從庫都執行了該事務才返回給客戶端。由於須要等待全部從庫執行完該事務才能返回，因此全同步複製的性能必然會收到嚴重的影響。

半同步複製（Semisynchronous replication）

    介於異步複製和全同步複製之間，主庫在執行完客戶端提交的事務後不是馬上返回給客戶端，而是等待至少一個從庫接收到並寫到relay log中才返回給客戶端。相對於異步複製，半同步複製提升了數據的安全性，同時它也形成了必定程度的延遲，這個延遲最少是一個TCP/IP往返的時間。因此，半同步複製最好在低延時的網絡中使用。

---

主從複製：

    MySQL主從複製的原理就是從服務器讀取主服務器的binlog，而後根據binlog的記錄來更新數據庫。

    MySQL的replication是一個異步的複製過程，在master和slave之間實現整個複製過程主要由3個線程來完成，在slave端有IO和SQL線程，這兩個線程的狀態必須是yes。

    mysql主從架構中其實就一個主在工做，而從就至關於一個備份機器，從經過日誌監測的方式來備份主庫上的數據而保證主庫的數據安全。在這種架構中若是從上的數據作了改變，主數據是不會發生任何變化的。

 

通常經過 主從複製（Master-Slave）的方式來同步數據，再經過讀寫分離（MySQL-Proxy）來提高數據庫的併發負載能力

---

MYSQL5.5版本特性：

1.引擎的變動---linux下默認innodb

2.cpu內核以及cpu物理數支持增長  

3.複製功能加強：支持半同步

4.加強表分區功能

---

 

 附：

 

MySQL 5.1 中，在複製方面的改進就是引進了新的複製技術：基於行的複製。

簡言之，這種新技術就是關注表中發生變化的記錄，而非之前的照抄 binlog 模式。

從 MySQL 5.1.12 開始，能夠用如下三種模式來實現：

-- 基於SQL語句的複製(statement-based replication, SBR)：在主服務器上執行的SQL語句，在從服務器上執行一樣的語句。MySQL默認採用基於語句的複製，效率比較高。 一旦發現無法精確複製時， 會自動選擇基於行的複製。

-- 基於行的複製(row-based replication, RBR)：把改變的內容複製過去，而不是把命令在從服務器上執行一遍. 從mysql5.0開始支持

-- 混合模式複製(mixed-based replication, MBR)：混合類型的複製: 默認採用基於語句的複製，一旦發現基於語句的沒法精確的複製時，就會採用基於行的複製。

相應地，binlog的格式也有三種：STATEMENT，ROW，MIXED。 MBR 模式中，SBR 是默認的。

在運行時能夠動態低改變binlog的格式，除了如下幾種狀況：

. 存儲過程或者觸發器中間

. 啓用了NDB

. 當前會話試用 RBR 模式，而且已打開了臨時表

若是binlog採用了 MIXED 模式，那麼在如下幾種狀況下會自動將binlog的模式由 SBR 模式改爲 RBR 模式。

. 當DML語句更新一個NDB表時

. 當函數中包含 UUID() 時

. 2個及以上包含 AUTO_INCREMENT 字段的表被更新時

. 行任何 INSERT DELAYED 語句時

. 用 UDF 時

. 視圖中必需要求使用 RBR 時，例如建立視圖是使用了 UUID() 函數

設定主從複製模式的方法很是簡單，只要在之前設定複製配置的基礎上，再加一個參數：

binlog_format="STATEMENT"

#binlog_format="ROW"

#binlog_format="MIXED"

固然了，也能夠在運行時動態修改binlog的格式。例如

mysql> SET SESSION binlog_format = 'STATEMENT';

mysql> SET SESSION binlog_format = 'ROW';

mysql> SET SESSION binlog_format = 'MIXED';

mysql> SET GLOBAL binlog_format = 'STATEMENT';

mysql> SET GLOBAL binlog_format = 'ROW';

mysql> SET GLOBAL binlog_format = 'MIXED';

兩種模式各自的優缺點：

SBR 的優勢：

歷史悠久，技術成熟

binlog文件較小

binlog中包含了全部數據庫更改信息，能夠據此來審覈數據庫的安全等狀況

binlog能夠用於實時的還原，而不只僅用於複製

主從版本能夠不同，從服務器版本能夠比主服務器版本高

SBR 的缺點：

不是全部的UPDATE語句都能被複制，尤爲是包含不肯定操做的時候。

調用具備不肯定因素的 UDF 時複製也可能出問題

使用如下函數的語句也沒法被複制：

* LOAD_FILE()

* UUID()

* USER()

* FOUND_ROWS()

* SYSDATE() (除非啓動時啓用了 --sysdate-is-now 選項)

INSERT ... SELECT 會產生比 RBR 更多的行級鎖

複製須要進行全表掃描(WHERE 語句中沒有使用到索引)的 UPDATE 時，須要比 RBR 請求更多的行級鎖

對於有 AUTO_INCREMENT 字段的 InnoDB表而言，INSERT 語句會阻塞其餘 INSERT 語句

對於一些複雜的語句，在從服務器上的耗資源狀況會更嚴重，而 RBR 模式下，只會對那個發生變化的記錄產生影響

存儲函數(不是存儲過程)在被調用的同時也會執行一次 NOW() 函數，這個能夠說是壞事也多是好事

肯定了的 UDF 也須要在從服務器上執行

數據表必須幾乎和主服務器保持一致才行，不然可能會致使複製出錯

執行復雜語句若是出錯的話，會消耗更多資源

 

RBR 的優勢：

任何狀況均可以被複制，這對複製來講是最安全可靠的

和其餘大多數數據庫系統的複製技術同樣

多數狀況下，從服務器上的表若是有主鍵的話，複製就會快了不少

複製如下幾種語句時的行鎖更少：

* INSERT ... SELECT

* 包含 AUTO_INCREMENT 字段的 INSERT

* 沒有附帶條件或者並無修改不少記錄的 UPDATE 或 DELETE 語句

執行 INSERT，UPDATE，DELETE 語句時鎖更少

從服務器上採用多線程來執行復製成爲可能

RBR 的缺點：

binlog 大了不少

複雜的回滾時 binlog 中會包含大量的數據

主服務器上執行 UPDATE 語句時，全部發生變化的記錄都會寫到 binlog 中，而 SBR 只會寫一次，這會致使頻繁發生 binlog 的併發寫問題

UDF 產生的大 BLOB 值會致使複製變慢

沒法從 binlog 中看到都複製了寫什麼語句(加密過的)

當在非事務表上執行一段堆積的SQL語句時，最好採用 SBR 模式，不然很容易致使主從服務器的數據不一致狀況發生

另外，針對系統庫 mysql 裏面的表發生變化時的處理規則以下：

若是是採用 INSERT，UPDATE，DELETE 直接操做表的狀況，則日誌格式根據 binlog_format 的設定而記錄

若是是採用 GRANT，REVOKE，SET PASSWORD 等管理語句來作的話，那麼不管如何都採用 SBR 模式記錄

注：採用 RBR 模式後，能解決不少原先出現的主鍵重複問題。

實例:

對於insert into db_allot_ids select * from db_allot_ids 這個語句:

在BINLOG_FORMAT=STATEMENT 模式下:

BINLOG日誌信息爲:

-----------------------------------------

BEGIN

/*!*/;

# at 173

#090612 16:05:42 server id 1 end_log_pos 288 Query thread_id=4 exec_time=0 error_code=0

SET TIMESTAMP=1244793942/*!*/;

insert into db_allot_ids select * from db_allot_ids

/*!*/;

-----------------------------------------

在BINLOG_FORMAT=ROW 模式下:

BINLOG日誌信息爲:

-----------------------------------------

BINLOG '

hA0yShMBAAAAMwAAAOAAAAAAAA8AAAAAAAAAA1NOUwAMZGJfYWxsb3RfaWRzAAIBAwAA

hA0yShcBAAAANQAAABUBAAAQAA8AAAAAAAEAAv/8AQEAAAD8AQEAAAD8AQEAAAD8AQEAAAA=

'/*!*/;

-----------------------------------------