❶ 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種方式：
❷ 在標准sql中，事務的隔離級別包含哪些
spring的事務處理主要是依靠AOP實現的，這個沒什麼好說的隨便搜索一下，網上很多示例。隔離級別是針對並發事務而言的，單個事務的處理很簡單不多說。並發事務的處理則比較復雜，因為往往一條數據是跨事務的，這會造成許多不可預知的後果。一般來說，系統執行並發事務時，會把當前在執行的事務獨立起來，也就是和其他事務進行隔離。好像系統中只有這一個事務，其他事務不存在一樣。這也就是完全隔離，即系統中只運行單位時間內，最多隻有一個事務在執行，其他事務要等到該事務執行完畢之後才能執行，這在現實中基本是不可行的，比如，你要更新你的QQ用戶信息，那麼就是說，在你更新的這段時間內，其他的用戶是無法更新他的用戶信息的。舉個深動的例子，把事務比作一條在公路上奔跑的汽車，完全隔離，就像是，在汽車從公路一頭到另一頭這段時間內，公路上不允許有其他的汽車，這樣做當然可以完全避免車禍，也就是數據跨事務帶來的隱患風險，但是帶來了巨大的效率問題，那麼如果同時在公路上讓多輛汽車行駛會造成什麼情況呢。具體來說有一下幾種：更新丟失（LostUpdate）：兩個事務都企圖去更新一行數據，導致事務拋出異常退出，兩個事務的更新都白費了。臟數據（DirtyRead）：如果第二個應用程序使用了第一個應用程序修改過的數據，而這個數據處於未提交狀態，這時就會發生臟讀。第一個應用程序隨後可能會請求回滾被修改的數據，從而導致第二個事務使用的數據被損壞，即所謂的「變臟」。不可重讀（UnrepeatableRead）：一個事務兩次讀同一行數據，可是這兩次讀到的數據不一樣，就叫不可重讀。如果一個事務在提交數據之前，另一個事務可以修改和刪除這些數據，就會發生不可重讀。幻讀（PhantomRead）：一個事務執行了兩次查詢，發現第二次查詢結果比第一次查詢多出了一行，這可能是因為另一個事務在這兩次查詢之間插入了新行。以上就是並行事務處理時常遇到的大致問題。針對這些問題，提出了幾個不同的事務隔離級別，適應特定的環境需要。具體是：讀操作未提交（ReadUncommitted）：說明一個事務在提交前，其變化對於其他事務來說是可見的。這樣臟讀、不可重讀和幻讀都是允許的。當一個事務已經寫入一行數據但未提交，其他事務都不能再寫入此行數據；但是，任何事務都可以讀任何數據。這個隔離級別使用排寫鎖實現。讀操作已提交（ReadCommitted）：讀取未提交的數據是不允許的，它使用臨時的共讀鎖和排寫鎖實現。這種隔離級別不允許臟讀，但不可重讀和幻讀是允許的。可重讀（RepeatableRead）：說明事務保證能夠再次讀取相同的數據而不會失敗。此隔離級別不允許臟讀和不可重讀，但幻讀會出現。可串列化（Serializable）：提供最嚴格的事務隔離。這個隔離級別不允許事務並行執行，只允許串列執行。這樣，臟讀、不可重讀或幻讀都可發生
❸ Windows Server 2016第三版技術預覽帶來了哪些新特性
隨著Windows Server 2016和System Center2016第 三版技術預覽的發布，我們也迎來了全新的里程碑。藉助這兩個分別針對混合雲和數據中心的解決方案的推出，微軟希望能夠幫助用戶將雲計算的靈活性引入企業。 對於微軟來說，這些里程碑式的產品在公司發展歷程中扮演了重要角色，它讓我們有機會了解各個用戶群體的看法。我們也希望用戶能夠從一開始就了解我們推出此 產品的初衷、熟悉新的功能，並了解這項新技術將如何改進你的業務。
對於用戶來說，此次的亮點是首次發布的Windows Server容器。這是將容器技術帶入WindowsServer生態系統的第一步，我們對隨之而來的可能性感到非常興奮。你可能已經看到容器技術的發展勢頭，這種新技術可以簡化應用的開發與部署。我們致力於讓容器技術成為現代應用平台的一部分，並將其整合在2016年推出的數據中心解決方案中，提供給我們的客戶。您可以通過MikeNeil的博客了解有關於容器技術創新的更多信息。
容器僅僅是Windows Server和SystemCenter技術預覽版眾多新特性中的一個。除此之外，我們還增強了上一個預覽版中的功能，並添加了一些新的特性，供你第一時間進行評估。
Nano Server
作為最小的內存部署選項，就像在技術預覽版2階段一樣，Nano Server可以被安裝在物理主機或虛擬機上。新的EmergencyManagement Console讓用戶可以在NanoServer控制台中直接查看和修復網路配置。此外，我們還提供PowerShell腳本用於創建一個運行NanoServer的Azure虛擬機。從應用的角度來說，你現在可以使用CoreCLR運行ASP.Netv5應用。總而言之，我們增加了重大功能以擴展Nano Server能力，而這一切的更新都建立在維持原有內存佔用的基礎之上。
軟體定義網路
在第三版技術預覽中，你會發現絕大多數網路功能是新增的。我們引入了用於編程政策的可擴展網路控制器、用於高可用性和高性能的L4負載均衡器、用於混合連接的增強網關，以及融合了RDMA流量和租戶流量的底層網路結構。在此次發布的預覽版中，你將首次體驗到我們在Azure中使用的核心網路功能套件和SDN架構。
安全
此次發布的預覽版增加了對於Hyper-V的投入：包括某些用於下一版本的安全創新。虛擬機隔離是我們承諾的核心，即幫助你保護共享環境中的資源。現在，你可以通過一個署名模板測試創建一個屏蔽虛擬機，以及該新屏蔽虛擬機的其他功能。你還可以發現WindowsServer扮演的全新角色——Host Guardian Service，管理員可以識別合法主機。
工作負載支持
● 用於增強關鍵工作復雜支持的附加特性和功能包括：
● 藉助擁有OpenGL支持的Remote Desktop Services提高應用兼容性。
● 藉助Storage Replica，對面向延展集群的站點感知而改進業務連續性場景。
● 通過為SQL Server集群刪除特定域容器而增加靈活性。
管理
在System Center 2016第三版技術預覽版中，增強的特性簡化了WindowsServer中新功能的管理。包括對Virtual Machine Manager的改進，如支持集群節點的滾動升級，支持NanoServer作為主機和文件伺服器。通過輕松管理隔離虛擬機和受保護主機，你還可以充分利用我們針對共享環境的安全增強功能。在存儲方面，你會看到改進的功能，以保持滿足預期的端對端服務質量（QoS）和更快速的數據（使用存儲分層）檢索。在OperationsManager中，我們則側重於通過管理包的可發現性，和使用PowerShel自動化維護窗口的能力，來提升用戶體驗。
此外，我們還發布了面向Windows 10客戶端的Remote Server AdministrationTools（RSAT），實現對Windows Server 2016技術預覽版、Windows Server 2012R2和Windows Server 2012的遠程管理。
更多的新特性待你評估，詳情可查看Experience Guides；我們還歡迎各位參加我們的User Voice計劃，參與整個開發過程。目前Windows Server 2016第三版技術預覽及System Center 2016第三版技術預覽都已經開放下載。期待來自你的建議。
注意：以上提到的軟體、特性及功能均基於預覽版，實際發布時可能會有所不同。
❹ 用sql資料庫做個小程序，實現數據隔離，怎麼控制
看了你的需求，首頁區分下概念，分清哪些是資料庫中的設置的，哪些是在程序中設置的。
第一個問題：
連接資料庫時的登錄名：就是登陸Sql Server的賬號（sa為默認的最高許可權）；在sql中稱為登陸名，可以在sql中新建登陸名，該登陸名可以設置sql的登陸許可權，在新建登陸名時用戶映射中，設置該登陸名可以訪問的資料庫名。登陸名包含了登陸許可權（就是獲取資料庫許可權的用戶名）。登陸名下包含了伺服器角色（批處理許可權的角色）信息，一般有sysadmin（sa）、public（新建的、默認）等。
上述用戶是sql中設置的信息，與程序無關。而程序使用的登陸用戶名是在sql中新建一個資料庫（AA），然後在資料庫中在新建一張用戶表（User），即你所說的用戶表包含了序號（ID）、用戶名（UID）、密碼（PWD）、身份（LOGIN）4個欄位。程序的登陸名只是User表中的一個欄位（UID）。
第二個問題：
首要要更正你的觀點，既然是程序裡面要在登陸時要實現不同的身份查看不同的數據，那麼所有的問題都由程序來做，與資料庫無關。只不過在資料庫AA里建立不同的表，存放不同的數據。因此總體設計如下：
1、建立sql資料庫連接登陸名，只需要一個，用默認的sa也可以
2、建立資料庫AA
3、建立各數據表。包括User表，User表中的用戶名（UID）即程序登陸用戶名
程序設計
4、程序建立與sql server的連接（即用1中新建的，sa也可以）
5、製作登陸驗證程序。首頁驗證UID與PWD是否匹配，其次根據不同的LOGIN跳轉不同的界面
6、在各自不同的界面調用所需要的數據
希望你能看明白！
❺ 資料庫的事務隔離級別,以及怎麼解決這些問題
SQL標準定義了四種隔離級別:
目前mysql默認使用可重復讀隔離級別.
❻ 標准SQL規范中定義的四個事務隔離級別
在標准SQL規范中，定義了4個事務隔離級別，不同的隔離級別對事務的處理不同:
◆未授權讀取(Read Uncommitted)：允許臟讀取，但不允許更新丟失。如果一個事務已經開始寫數據，則另外一個數據則不允許同時進行寫操作，但允許其他事務讀此行數據。該隔離級別可以通過「排他寫鎖」實現。
◆授權讀取(Read Committed)：允許不可重復讀取，但不允許臟讀取。這可以通過「瞬間共享讀鎖」和「排他寫鎖」實現。讀取數據的事務允許其他事務繼續訪問該行數據，但是未提交的寫事務將會禁止其他事務訪問該行。
◆可重復讀取(Repeatable Read)：禁止不可重復讀取和臟讀取，但是有時可能出現幻影數據。這可以通過「共享讀鎖」和「排他寫鎖」實現。讀取數據的事務將會禁止寫事務(但允許讀事務)，寫事務則禁止任何其他事務。
◆序列化(Serializable)：提供嚴格的事務隔離。它要求事務序列化執行，事務只能一個接著一個地執行，但不能並發執行。如果僅僅通過「行級鎖」是無法實現事務序列化的，必須通過其他機制保證新插入的數據不會被剛執行查詢操作的事務訪問到。
隔離級別越高，越能保證數據的完整性和一致性，但是對並發性能的影響也越大。對於多數應用程序，可以優先考慮把資料庫系統的隔離級別設為Read Committed，它能夠避免臟讀取，而且具有較好的並發性能。盡管它會導致不可重復讀、虛讀和第二類丟失更新這些並發問題，在可能出現這類問題的個別場合，可以由應用程序採用悲觀鎖或樂觀鎖來控制。
通過前面的介紹已經知道，通過選用不同的隔離等級就可以在不同程度上避免前面所提及的在事務處理中所面臨的各種問題。所以，資料庫隔離級別的選取鎮此就顯得尤為重要，在選取資料庫的隔離級別時，應該注意以下幾個處理的原則：
首先，必須排除「未授權讀取」，因為在多個事務之間使用它將會是非常危險的。事務的回滾操作或失敗將會影響到其他並發事務。第一個事務的回滾將會完全將其他事務的操作清除，甚至使資料庫處在一個不一致的狀態。很可能一個已回滾為結束的事務對數據的修改最後卻修改提交了，因為「未授權讀取」允許其他事務讀取數據，最後整個錯誤狀態在其他事務之間傳播開來。
其次，絕大部分應用都無須使用「序列化御液迅」隔離(一般來說，讀取幻影數據並不是一個問題)，此隔離級別也難以測量。目前使用序列化隔離的應用中，一般都使用悲觀鎖，這樣強行使所有事務都序列化執行。
剩下的也就是在「授權讀取」和「可重復讀取」之間選擇了。我們先考慮可重復讀取。如果所有的數據訪問都是在統一的原子資料庫事務中，此隔離級別將消除一個事務在另外一個並發事務過程中覆蓋數據的可能性(第二個事務更新丟失問題)。這是一個非常重要的問題，但是使用可重復讀取並不是解決問題的途徑。
假設使用了「版本數據」，Hibernate會自動使用版本數據。Hibernate的一級Session緩存和版本數據已經為你提供了「可重復讀取隔離」絕大部分的特性。特別是，版本數據可以防止二次更新丟失的問題，一級Session緩存可以保證持久載入數據的狀態與其他事務對數據的修改隔離開來，因此如果使用對所有的資料庫事務採用授權讀取隔離和版本數據是行得通的。
「可重復讀取」為資料庫查詢提供了更好的效率(僅對那些長時間的資料庫事務)，但是由於幻影讀取依然存在，因此沒必要使用它(對於Web應用來說，一般也很少在一個資料庫事務中對同一個表查詢兩次)。
也可以同時考慮選擇使用Hibernate的二級緩存，它可以如同底層埋斗的資料庫事務一樣提供相同的事務隔離，但是它可能弱化隔離。假如在二級緩存大量使用緩存並發策略，它並不提供重復讀取語義(例如，後面章節中將要討論的讀寫，特別是非嚴格讀寫)，很容易可以選擇默認的隔離級別：因為無論如何都無法實現「可重復讀取」，因此就更沒有必要拖慢資料庫了。另一方面，可能對關鍵類不採用二級緩存，或者採用一個完全的事務緩存，提供「可重復讀取隔離」。那麼在業務中需要使用到「可重復讀取」嗎?如果你喜歡，當然可以那樣做，但更多的時候並沒有必要花費這個代價。
❼ sql server 2008 事務 的 隔離性 怎麼理解
沒什麼特殊的地方 開啟一個事務,然後執行必要的操作, 最後提交就行了, 出錯的地方可以進行回滾 PL/SQL如果沒有使用顯式事務,它會自動給你添加一個隱式的