轉自：https://blog.csdn.net/yangjiechao945/article/details/81355558
為什么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也就沒有意義了。。.
最后總結：SQLServer數據庫 查詢時不加 with(nolock)可能會導致查詢阻塞，加了可能導致臟讀（但此時用戶A讀取到的是新的數據，但是用戶B在事務中修改該數據沒有提交的話，可能會回滾，這時候用戶A讀取的數據是B修改后的數據，但是B回滾的話，用戶A讀的數據就不是真實的數據了）