數據庫系統工作原理：
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=
'/*!*/;
-----------------------------------------