.Net轉Java.05.爲啥MySQL沒有nolock

今天突然想到一個問題，原來爲了提升SQL Server性能，公司規定查詢語句通常都要加 WITH (NOLOCK)的

如今轉Java了，用了MySQL爲啥不提這個事情了？

 

先在MySQL裏寫了一個查詢語句，比樣子加了nolock，提示語法不正確，難道是用READUNCOMMITTED?  依然提示語法不正確，

看來MySQL是不支持nolock之類的語法

而後的問題變成了，爲何MySQL不須要支持nolock之類的語法,或者若是MySQL不支持nolock，修改記錄致使鎖表怎麼辦？

因此我作了下面的實驗

給開了兩個MySQL鏈接，（順便插一句，由於用的客戶端是SQLyog，本覺得跟SQL Server Management Studio同樣每一個「詢問」就是一個鏈接，其實不是，每一個鏈接都要「建立新鏈接」，我本身測試半天才發現這個問題）

 第一個MySQL鏈接執行查詢

START TRANSACTION;
UPDATE testtable SET NAME='newvalue' WHERE id=1

由於事務沒有提交，若是是SQLServer的默認狀況下，第二個鏈接再查詢同一條記錄，確定會被阻塞的。若是SQLServer查詢加了Nolock讀取到的是還未commit的髒值「newvalue」

第二個MySQL鏈接我執行查詢

SELECT * FROM `testtable`

我發現既沒有發生阻塞，也沒有發生髒讀，查詢到的是老的值，並無讀到未提交的新值newvalue

也就是說MySQL和SQLServer默認維護事務的機制是不一樣的，

SQLServer 默認狀況下一個事務修改了某個值，在這個事務提交前，是阻塞其餘鏈接來讀取這個修改中的值的，若是加nolock讀取到的是修改後爲提交的值（也就是髒讀，由於可能這個值最終會回滾）

MySQL 默認狀況下，一個事務修改了某個值，在這個事務提交前，不阻塞其餘鏈接來讀取這個修改中的值，而且讀取到的是修改前的值。

對於互聯網公司，絕大多數場景，都不但願寫的事務來阻塞讀，

因此SQLServer建議加nolock

MySQL自己就不阻塞，nolock也就沒有意義了。。