mysql 驅動的版本問題

1：版本

    Connector/J 5.1 支持Mysql 4.一、Mysql 5.0、Mysql 5.一、Mysql 6.0 alpha這些版本。
    Connector/J 5.0 支持MySQL 4.一、MySQL 5.0 servers、distributed transaction (XA)。
    Connector/J 3.1 支持MySQL 4.一、MySQL 5.0 servers、MySQL 5.0 except distributed transaction (XA) support。
    Connector/J 3.0 支持MySQL 3.x or MySQL 4.1。

 

2：體系結構（轉）

---http://www.cnblogs.com/chenmh/p/4914754.html

概述  

學習一門數據庫系統首先得了解它的架構，明白它的架構原理對於後期的分析問題和性能調優都有很大的幫助，接下來就經過分析架構圖來認識它。

目錄

•  概述
•  架構圖
•  總結

架構圖

 

1.鏈接管理與安全驗證

每一個客戶端都會創建一個與服務器鏈接的線程，服務器會有一個線程池來管理這些鏈接；若是客戶端須要鏈接到MYSQL數據庫還須要進行驗證，包括用戶名、密碼、主機信息等。

2.解析器

解析器的做用主要是分析查詢語句，最終生成解析樹；首先解析器會對查詢語句的語法進行分析，分析語法是否有問題。還有解析器會查詢緩存，若是在緩存中有對應的語句，就返回查詢結果不進行接下來的優化執行操做。前提是緩存中的數據沒有被修改，固然若是被修改了也會被清出緩存。

在有的書籍中會把查詢緩存放在解析以前，難道不須要判斷語法是否有錯誤嗎？若是有知道的麻煩幫忙解惑。

3.優化器

優化器的做用主要是對查詢語句進行優化操做，包括選擇合適的索引，數據的讀取方式，包括獲取查詢的開銷信息，統計信息等，這也是爲何圖中會有優化器指向存儲引擎的箭頭。以前在別的文章沒有看到優化器跟存儲引擎之間的關係，在這裏我我的的理解是由於優化器須要經過存儲引擎獲取查詢的大體數據和統計信息。

4.執行器

執行器包括執行查詢語句，返回查詢結果，生成執行計劃包括與存儲引擎的一些處理操做。

存儲引擎

1.鎖的種類

鎖的由來是爲了解決併發控制，對於一個查詢語句爲了避免讓查詢的數據被其它語句所更改就須要將數據附加鎖，咱們比較熟悉的鎖有共享鎖和排他鎖。

2.鎖的粒度

任何一種操做都須要消耗資源，附加鎖一樣也會消耗資源，一樣的一個查詢若是咱們鎖定的資源越少那麼併發就越高同時資源消耗越大，反之併發低消耗越小。

  表鎖(table lock)

表鎖是MYSQL裏面資源消耗最小的鎖，只須要在查詢對應的表上附加鎖就能夠了。一個SQL語句首先須要得到鎖，首先查詢語句會判斷表上面是否存在鎖，若是表上面有排他鎖那麼查詢語句就會等待，因此查詢語句只須要獲取一次鎖就能夠了，不須要再往下一層去判斷是否存在行鎖，鎖資源消耗低。同時若是有一個排他鎖附加在該表上面其它的語句都須要等待改鎖釋放，系統的併發度很低。

 行鎖（row lock）

行鎖與表鎖恰好相反，一個update語句首先它會判斷對應的表是否存在排他鎖，若是不存在接下來會判斷對應的更新記錄上面是否存在鎖，若是不存在附加排他鎖。行鎖的獲取鎖資源方面消耗比表鎖更多，可是因爲它只在對應的記錄行上面添加鎖，不影響對應表的其它記錄行，系統的併發度比表鎖要高。

 死鎖

在一個高併發的系統中，因爲鎖和事務的存在每每會有死鎖的狀況發生。舉個簡單的死鎖的例子，假如兩個事務同時執行。

事務1
START TRANSACTION;
UPDATE USER SET NAME='張三' WHERE ID=1
等待5秒
UPDATE USER SET NAME='李四' WHERE ID=2
COMMIT;

事務2
START TRANSACTION;
UPDATE USER SET NAME='張三' WHERE ID=2
等待5秒
UPDATE USER SET NAME='李四' WHERE ID=1
COMMIT;

因爲兩個事務在更新第一天語句的時候都鎖定了對應的行記錄，當進行次日更新語句的時候因爲對應的記錄行已經被鎖定須要等待，陷入了死循環，這就是常見的死鎖的狀況。

 

3.事務

mysql和其它的數據庫產品有一個很大的不一樣就是事務由存儲引擎所決定，例如MYISAM,MEMORY,ARCHIVE都不支持事務，事務就是爲了解決一組查詢要麼所有執行成功，要麼所有執行失敗。

mysql事務默認是採起自動提交的模式，除非顯示開始一個事務

SHOW VARIABLES LIKE 'AUTOCOMMIT';

修改自動提交模式，0=OFF,1=ON

注意：修改自動提交對非事務類型的表是無效的，由於它們自己就沒有提交和回滾的概念，還有一些命令是會強制自動提交的，好比DLL命令、lock tables等。

SET AUTOCOMMIT=OFF
或
SET AUTOCOMMIT=0

你們可能比較熟悉的就是事務的ACID特性：原子性，一致性，隔離性，持久性。

原子性：事務是不可分割的最小工做單元，整個事務要麼所有提交要麼所有回滾失敗。

一致性：數據庫老是從一個一致性狀態轉換到另外一個一致性的狀態。

隔離性： 一個事務所作的更改在最終提交以前其它事務是不可見的。

持久性：事務一旦提交所作的修改就會永久保存在數據庫中，即便系統崩潰，數據也不會丟失。

 

隔離級別

隔離級別是用來規定一個事務所作的更改，一般會默認系統使用哪種隔離級別，一般隔離級別越高系統的併發就越低，系統開銷也越大，mysql有四種隔離級別分別是：

未提交讀（READ UNCOMMITTED）：未提交讀隔離級別也叫讀髒，就是事務能夠讀取其它事務未提交的數據。

提交讀（READ COMMITTED）:在其它數據庫系統好比SQL Server默認的隔離級別就是提交讀，已提交讀隔離級別就是在事務未提交以前所作的修改其它事務是不可見的。

可重複讀（REPEATABLE READ）:保證同一個事務中的屢次相同的查詢的結果是一致的，好比一個事務一開始查詢了一條記錄而後過了幾秒鐘又執行了相同的查詢，保證兩次查詢的結果是相同的，可重複讀也是mysql的默認隔離級別，。

可串行化（SERIALIZABLE）:可串行化就是保證讀取的範圍內沒有新的數據插入，好比事務第一次查詢獲得某個範圍的數據，第二次查詢也一樣獲得了相同範圍的數據，中間沒有新的數據插入到該範圍中。

查詢系統默認隔離級別、當前回話隔離級別
select @@global.tx_isolation,@@tx_isolation;

 分別設置系統和回話當前隔離級別爲可提交讀

/*設置系統當前隔離級別*/
SET global transaction isolation level read committed;

/*設置回話當前隔離級別*/
SET SESSION transaction isolation LEVEL read committed;

注意：在同一個事務中避免出現混合存儲引擎的表，好比混合了事務和非事務的表，正常提交不會有影響，若是出現了回滾操做，非事務的表的修改就沒法回滾這樣就會致使數據庫處於不一致的狀態，一旦出現這種狀況將很難修復，因此表選擇合適存儲引擎很重要。

隱式和顯示鎖定

所謂的隱式鎖定就是系統自動加鎖而不是認爲的添加鎖，INNODB採用兩段鎖定協議，在事務的執行過程當中隨時執行鎖定，在執行commit或者rollback的時候全部的鎖才同時釋放

顯示鎖定就是人爲的添加鎖，好比lock tables或者unlock tables，顯示鎖定是基於服務器層的設定和存儲引擎無關，就是無論你的表是myisam仍是innodb均可以顯示添加lock tables，可是myisam自己就是lock tables因此再顯示添加也畫蛇添足。

注意：避免在事務中使用lock tables

存儲

 存儲這塊知識放在後面單獨講解

總結

對於mysql的體系結構每一個人的理解可能會有所不一樣，上圖是根據本身的理解繪製的不是官方標準的體系結構，僅供參考，若是有不對的地方歡迎討論，接下來的文章會是關於存儲方面的文章，歡迎關注。