1. mysql默認事務隔離級別
SQL標准中支持4種事務隔離級別，READ_UNCOMMITTED（讀未提交），READ_COMMITTED（讀已提交），REPEATABLE_READ（可重復讀），SERIALIZABLE（串列讀），MySQL innodb引擎支持全部這4種事務隔離級別。
工具／原料：
聯想Y7000P
Windows10
MySQL6.0
1、啟動命令行窗口，連接MySQL資料庫
圖示，通過MySQL提供的客戶端命令mysql連接MySQL資料庫。
2. 怎麼查看資料庫隔離級別
1.查看當前會話隔離級別仿如
select @@tx_isolation;
2.查褲消看系統當前隔離級別
select @@global.tx_isolation;
3.設置當前會話隔離胡大知級別
set session transaction isolatin level repeatable read;
4.設置系統當前隔離級別
set global transaction isolation level repeatable read;
5.命令行，開始事務時
3. mysql隔離級別
MySQL 中事務的隔離級別一共分為四種，分別如下：
序列化（SERIALIZABLE）：如果隔離級別為序列化，則用戶之間通過一個接一個順序地執行當前的事務，這種隔離級別提供了事務之間最大限度的隔離。
可重復讀（REPEATABLE READ）：在可重復讀在這一隔離級別上，事務不會被看成是一個序列。不過，當前正在執行事務的變化仍然不能被外部看到，也就是說，如果用戶在另外一個事務中執行同條 SELECT 語句數次，結果總是相同的。（因為正在執行的事務所產生的數據變化不能被外部看到）。
提交讀（READ COMMITTED）：READ COMMITTED 隔離級別的安全性比 REPEATABLE READ 隔離級別的安全性要差。處於 READ COMMITTED 級別的事務可以看到其他事務對數據的修改。也就是說，在事務處理期間，如果其他事務修改了相應的表，那麼同一個事務的多個 SELECT 語句可能返回不同的結果。
未提交讀（READ UNCOMMITTED）：READ UNCOMMITTED 提供了事務之間最小限度的隔離。除了容易產生虛幻的讀操作和不能重復的讀操作外，處於這個隔離級的事務可以讀到其他事務還沒有提交的數據，如果這個事務使用其他事務不提交的變化作為計算的基礎，然後那些未提交的變化被它們的父事務撤銷，這就導致了大量的數據變化。
應用環境
與其他的大型資料庫例如Oracle、DB2、SQL Server等相比，MySQL自有它的不足之處，但是這絲毫也沒有減少它受歡迎的程度。對於一般的個人使用者和中小型企業來說，MySQL提供的功能已經綽綽有餘，而且由於 MySQL是開放源碼軟體，因此可以大大降低總體擁有成本。
4. MySQL的默認事務隔離級別是
mysql的4種事務隔離級別，如下所示：
1、未提交讀(Read Uncommitted)：允許臟讀，也就是可能讀取到其他會話中未提交事務修改的數據。
2、提交讀(Read Committed)：只能讀取到已經提交的數據。Oracle等多數資料庫默認都是該級別 (不重復讀)。
3、可重復讀(Repeated Read)：可重復讀。在同一個事務內的查詢都是事務開始時刻一致的，InnoDB默認級別。在SQL標准中，該隔離級別消除了不可重復讀，但是還存在幻象讀，但是innoDB解決了幻讀。
4、串列讀(Serializable)：完全串列化的讀，每次讀都需要獲得表級共享鎖，讀寫相互都會阻塞。
相關簡介
MySQL是一個關系型資料庫管理系統，由瑞典MySQL AB公司開發，屬於Oracle旗下產品。MySQL 是最流行的關系型資料庫管理系統之一，在WEB應用方面，MySQL是最好的RDBMS(Relational Database Management System，關系資料庫管理系統) 應用軟體之一。
MySQL是一種關系型資料庫管理系統，關系資料庫將數據保存在不同的表中，而不是將所有數據放在一個大倉庫內，這樣就增加了速度並提高了靈活性。
MySQL所使用的 SQL 語言是用於訪問資料庫的最常用標准化語言。MySQL 軟體採用了雙授權政策，分為社區版和商業版，由於其體積小、速度快、總體擁有成本低，尤其是開放源碼這一特點，一般中小型網站的開發都選擇 MySQL 作為網站資料庫。
5. 怎麼查看資料庫隔離級別
修改方法
有兩種方法可以對配置了 systemd 的程序進行資源隔離：1. 命令行修改：通過執行systemctl set-property命令實現，形式為systemctl set-propertyname parameter=value；修改默認即時生效。2. 手工修改文件：直接編輯程序的 systemd unit file 文件，完成之後需手工執行systemctldaemon-reload更念猜新配置，並重啟服務systemctl restart name.service。
systemd unit file 里支持的資源隔離配置項，如常見的：
CPUQuota=value
該參數表示服務可以獲取的最大 CPU 時間，value 為百分數形式，高於 100% 表示可使用1 核以上的CPU。與 cgroup cpu 控制器cpu.cfs_quota_us配置項對應。
MemoryLimit=value
該參數表示服務可以使用的最大內存量，value 可以使用 K, M, G, T 等後綴表示值的大小。與 cgroupmemory 控制器memory.limit_in_bytes配置項對應。
事務的4種隔離級別
READ UNCOMMITTED 未提交讀，可以讀取未提交的數據。
READ COMMITTED 已提交讀，對於鎖定讀(select with for update 或拍嘩者 for share)、update 和 delete 語句，InnoDB 僅鎖定索引記錄，而襲高行不鎖定它們之間的間隙，因此允許在鎖定的記錄旁邊自由插入新記錄。
Gap locking 僅用於外鍵約束檢查和重復鍵檢查。
REPEATABLE READ 可重復讀，事務中的一致性讀取讀取的是事務第一次讀取所建立的快照。
SERIALIZABLE 序列化在了解了 4 種隔離級別的需求後，在採用鎖控制隔離級別的基礎上，我們需要了解加鎖的對象(數據本身&間隙)，以及了解整個數據范圍的全集組成。
數據范圍全集組成
SQL 語句根據條件判斷不需要掃描的數據范圍（不加鎖）；
SQL 語句根據條件掃描到的可能需要加鎖的數據范圍；
以單個數據范圍為例，數據范圍全集包含：（數據范圍不一定是連續的值，也可能是間隔的值組成）
6. mysql的事務四個特性以及事務的四個隔離級別
分別是原子性、一致性、隔離性、持久性。
原子性是指事務包含的所有操作要麼全部成功，要麼全部失敗回滾，因此事務的操作如果成功就必須要完全應用到資料庫，如果操作失敗則不能對資料庫有任何影響。
一致性是指事務必須使資料庫從一個一致性狀態變換到另一個一致性狀態，也就是說一個事務執行之前和執行之後都必須處於一致性狀態。舉例來說，假設用戶A和用戶B兩者的錢加起來一共是1000，那麼不管A和B之間如何轉賬、轉幾次賬，事務結束後兩個用戶的錢相加起來應該還得是1000，這就是事務的一致性。
隔離性是當多個用戶並發訪問資料庫時，比如同時操作同一張表時，資料庫為每一個用戶開啟的事務，不能被其他事務的操作所干擾，多個並發事務之間要相互隔離。關於事務的隔離性資料庫提供了多種隔離級別，稍後會介紹到。
持久性是指一個事務一旦被提交了，那麼對資料庫中的數據的改變就是永久性的，即便是在資料庫系統遇到故障的情況下也不會丟失提交事務的操作。例如我們在使用JDBC操作資料庫時，在提交事務方法後，提示用戶事務操作完成，當我們程序執行完成直到看到提示後，就可以認定事務已經正確提交，即使這時候資料庫出現了問題，也必須要將我們的事務完全執行完成。否則的話就會造成我們雖然看到提示事務處理完畢，但是資料庫因為故障而沒有執行事務的重大錯誤。這是不允許的。
在資料庫操作中，在並發的情況下可能出現如下問題：
正是為了解決以上情況，資料庫提供了幾種隔離級別。
資料庫事務的隔離級別有4個，由低到高依次為Read uncommitted(未授權讀取、讀未提交)、Read committed（授權讀取、讀提交）、Repeatable read（可重復讀取）、Serializable（序列化），這四個級別可以逐個解決臟讀、不可重復讀、幻象讀這幾類問題。
雖然資料庫的隔離級別可以解決大多數問題，但是靈活度較差，為此又提出了悲觀鎖和樂觀鎖的概念。
悲觀鎖，它指的是對數據被外界（包括本系統當前的其他事務，以及來自外部系統的事務處理）修改持保守態度。因此，在整個數據處理過程中，將數據處於鎖定狀態。悲觀鎖的實現，往往依靠資料庫提供的鎖機制。也只有資料庫層提供的鎖機制才能真正保證數據訪問的排他性，否則，即使在本系統的數據訪問層中實現了加鎖機制，也無法保證外部系統不會修改數據。
商品t_items表中有一個欄位status，status為1代表商品未被下單，status為2代表商品已經被下單（此時該商品無法再次下單），那麼我們對某個商品下單時必須確保該商品status為1。假設商品的id為1。
如果不採用鎖，那麼操作方法如下：
但是上面這種場景在高並發訪問的情況下很可能會出現問題。例如當第一步操作中，查詢出來的商品status為1。但是當我們執行第三步Update操作的時候，有可能出現其他人先一步對商品下單把t_items中的status修改為2了，但是我們並不知道數據已經被修改了，這樣就可能造成同一個商品被下單2次，使得數據不一致。所以說這種方式是不安全的。
在上面的場景中，商品信息從查詢出來到修改，中間有一個處理訂單的過程，使用悲觀鎖的原理就是，當我們在查詢出t_items信息後就把當前的數據鎖定，直到我們修改完畢後再解鎖。那麼在這個過程中，因為t_items被鎖定了，就不會出現有第三者來對其進行修改了。需要注意的是，要使用悲觀鎖，我們必須關閉mysql資料庫的自動提交屬性，因為MySQL默認使用autocommit模式，也就是說，當你執行一個更新操作後，MySQL會立刻將結果進行提交。我們可以使用命令設置MySQL為非autocommit模式： set autocommit=0;
設置完autocommit後，我們就可以執行我們的正常業務了。具體如下：
上面的begin/commit為事務的開始和結束，因為在前一步我們關閉了mysql的autocommit，所以需要手動控制事務的提交。
上面的第一步我們執行了一次查詢操作： select status from t_items where id=1 for update; 與普通查詢不一樣的是，我們使用了 select…for update 的方式，這樣就通過資料庫實現了悲觀鎖。此時在t_items表中，id為1的那條數據就被我們鎖定了，其它的事務必須等本次事務提交之後才能執行。這樣我們可以保證當前的數據不會被其它事務修改。需要注意的是，在事務中，只有 SELECT ... FOR UPDATE 或 LOCK IN SHARE MODE 操作同一個數據時才會等待其它事務結束後才執行，一般 SELECT ... 則不受此影響。拿上面的實例來說，當我執行 select status from t_items where id=1 for update; 後。我在另外的事務中如果再次執行 select status from t_items where id=1 for update; 則第二個事務會一直等待第一個事務的提交，此時第二個查詢處於阻塞的狀態，但是如果我是在第二個事務中執行 select status from t_items where id=1; 則能正常查詢出數據，不會受第一個事務的影響。
使用 select…for update 會把數據給鎖住，不過我們需要注意一些鎖的級別，MySQL InnoDB默認Row-Level Lock，所以只有「明確」地指定主鍵或者索引，MySQL 才會執行Row lock (只鎖住被選取的數據) ，否則MySQL 將會執行Table Lock (將整個數據表單給鎖住)。舉例如下：
1、 select * from t_items where id=1 for update;
這條語句明確指定主鍵（id=1），並且有此數據（id=1的數據存在），則採用row lock。只鎖定當前這條數據。
2、 select * from t_items where id=3 for update;
這條語句明確指定主鍵，但是卻查無此數據，此時不會產生lock（沒有元數據，又去lock誰呢？）。
3、 select * from t_items where name='手機' for update;
這條語句沒有指定數據的主鍵，那麼此時產生table lock，即在當前事務提交前整張數據表的所有欄位將無法被查詢。
4、 select * from t_items where id>0 for update; 或者 select * from t_items where id>1 for update; （註：>在SQL中表示不等於）
上述兩條語句的主鍵都不明確，也會產生table lock。
5、 select * from t_items where status=1 for update; （假設為status欄位添加了索引）
這條語句明確指定了索引，並且有此數據，則產生row lock。
6、 select * from t_items where status=3 for update; （假設為status欄位添加了索引）
這條語句明確指定索引，但是根據索引查無此數據，也就不會產生lock。
樂觀鎖（ Optimistic Locking ） 相對悲觀鎖而言，樂觀鎖假設認為數據一般情況下不會造成沖突，所以只會在數據進行提交更新的時候，才會正式對數據的沖突與否進行檢測，如果發現沖突了，則返回用戶錯誤的信息，讓用戶決定如何去做。實現樂觀鎖一般來說有以下2種方式：