現(xiàn)在常規(guī)的應用系統(tǒng)中喉镰，每一個接口基本都需要執(zhí)行多條更新SQL内贮。這就要求多條SQL的更新要么全部生效栖疑，要么全部都不生效讨永。這就是所謂的原子性，事務的四大特性之一遇革。MySQL原生的存儲引MyISAM是不支持事務的卿闹，因此大部分場景都需要用InnoDB存儲引擎揭糕，其也是新版MySQL的默認存儲引擎。
事務之ACID特性
Atomicity-原子性
Consistency-一致性
Isolation-隔離性
Durability-持久性
隔離級別是為了解決多個事務同時執(zhí)行過程中锻霎，會出現(xiàn)的臟讀插佛，不可重復讀和幻讀問題
臟讀-Dirty Read
讀到了其他事務未提交的更新，當那個事務回滾后量窘，這條更新就是臟數(shù)據(jù)了雇寇。
不可重復讀-Nonrepeatable Read
針對同一條數(shù)據(jù)，第一次讀的時候還未提交蚌铜，第二次再讀的時候锨侯，已經(jīng)提交了，所以讀到了冬殃。
幻讀-Phantom Read
針對范圍查詢囚痴，第二次再讀的時候，其他事務提交了一條更新审葬，在這個范圍內(nèi)深滚。對當前事務來說，
第二次讀的時候涣觉，比第一次讀的時候多了一條數(shù)據(jù)痴荐。
針對上面每種問題，數(shù)據(jù)庫規(guī)范官册？定義了四種隔離級別
READ_UNCOMMITED
當前事務可以看到其他事務未提交的更新
READ_COMMITED
當前事務只能讀到其他事務已提交的更新
REPEATABLE_READ
當前事務中任何時刻讀取的數(shù)據(jù)都一致生兆，即使其他事務的更新已經(jīng)提交了
SERIALIABLE
事務串行
各種隔離級別的實現(xiàn)方案，事務訪問的數(shù)據(jù)都是以視圖的邏輯結果為準膝宁。在REPEATABLE_READ隔離 級別下鸦难，這個視圖是在事務啟動時創(chuàng)建的，整個事務存在期間都用這個視圖员淫。在READ_COMMITED隔離級 別下合蔽，這個視圖是在每個SQL語句開始執(zhí)行的時候創(chuàng)建的。這里需要注意的是介返，READ_UNCOMMITED隔離級別下直接返回記錄上的最新值拴事，沒有視圖概念;而SERIALIABLE隔離級別下直接用加鎖的方式來避 免并行訪問。
綜上映皆，為解決多事務并發(fā)問題挤聘，針對不同問題采用不同的解決方案
1.MVVC-Multi Version Currency Control,利用undo log實現(xiàn)的視圖邏輯結果，具體實現(xiàn)方案見[http://www.reibang.com/p/f692d4f8a53e
2.加鎖捅彻，使事務串行執(zhí)行
問題：在具體實現(xiàn)中组去，兩種方案是怎么配合使用的？
試驗步淹，在實際試驗不同事務隔離級的效果時从隆，可以直接寫SQL試驗诚撵。
開啟事務的方式有以下兩種
begin;(或者 start transaction;)
sql statement;
commit; (回滾 rollback;)
set autocommit=0
開啟了事務，怎么指定事務隔離級別键闺。在MySQL中寿烟，事務隔離級別有
全局級
SELECT @@global.tx_isolation;
會話級
SELECT @@session.tx_isolation;
所有的？辛燥？筛武？
SELECT @@tx_isolation;
設置事務隔離的命令（不區(qū)分大小寫）
SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}
例如給當前連接上的事務設置隔離為讀未提交
set session transaction isolation level read uncommited
如果不指定session 或者global,則設置對下一個事務生效。（不是太懂）
試驗一把挎塌，在一個連接中更新徘六，但是不提交，在另一個連接中榴都，設置事務隔離級別為read uncommited 然后查詢待锈，看是否能看到更新。果然能看到嘴高。
有個問題竿音，每一條SQL都是在事務下執(zhí)行的。就算對于一個select語句來講拴驮，也是在事務中的春瞬，因為當前的事務隔離級別決定了他能看到什么樣的數(shù)據(jù)。
所謂只讀事務是什么概念莹汤？快鱼？
官方文檔更能直至本質(zhì)https://dev.mysql.com/doc/refman/5.7/en/innodb-autocommit-commit-rollback.html
一直講事務隔離級別，但是忽略了一個重要的概念纲岭，那就是autocommit。
根據(jù)上面的官方文檔线罕，所有的用戶行為（我的理解是執(zhí)行的任何DML語句）都是在事務里的（跟我上面的理解是一致的止潮，哈哈哈）。如果開啟了autocommit钞楼，每一個單獨的SQL都會產(chǎn)生一個屬于它自己的事務喇闸，所以SQL執(zhí)行成功后（當錯誤后的處理策略再研究），MySQL就會自動執(zhí)行commit操作询件。默認情況下燃乍，autocommit是開啟的。所以我們執(zhí)行完update insert等語句后宛琅，數(shù)據(jù)會及時持久化到磁盤刻蟹。問題來了，如果關閉autocommit會有什么影響嘿辟，這個配置是session級還是全局級的舆瘪？
第二個問題片效，通過試驗(set autocommit =0;)得出結論，關閉autocommit只在當前session中生效英古，其他session不受影響淀衣。
第一個問題，還是根據(jù)官方文檔召调，如果關閉autocommit膨桥，一個session默認會開啟事務，直到用戶執(zhí)行了commit或者rollback后唠叛，才會結束這個事務只嚣，并且再開啟一個新事務。
綜上玻墅，要想將多個SQL明確放在一個事務中介牙，便于統(tǒng)一提交或者回滾，有兩種方式
方式一澳厢、關閉autocommit环础，所有SQL執(zhí)行完之后，再commit或者rollback剩拢。
方式二线得、在執(zhí)行第一條SQL前，執(zhí)行begin或者start transaction,所有SQL執(zhí)行完之后徐伐，再commit或者rollback贯钩。
所以任何一條DML語句都是在事務中執(zhí)行的，區(qū)別在于事務的范圍（即包含了哪些SQL）以及事務的提交或者回滾執(zhí)行的時刻办素。講到這里角雷，發(fā)現(xiàn)事務跟線程的概念相似，任何一段代碼都是在某個線程中執(zhí)行的性穿，要么自己指定用哪個線程勺三，要么就是系統(tǒng)提供的主線程。
