mysql(InnoDB)事务隔离级别(READ UNCOMMITTED) 与 锁
https://segmentfault.com/a/1190000012654564
相同类型的还有
看到了吧读取UNCOMMITTED事务也不被排他锁(排他锁将阻止当前事务读取已被修改但未被其他事务提交的行)阻止 其实想想也对，应为排它锁对任何其他的事务开始之前申请的排它锁，共享锁都不兼容。但是如果我读不申请锁，就不会产生上述问题了呀。 所以最终结论是：read uncommitted 读不加锁，写加排他锁，并到事务结束之后释放。 作者：fxliutao 链接：https://www.jianshu.com/p/d75fcdeb07a3 來源：简书 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
我们主要看第一篇文章
结论：
1. 通过写－写 验证 写操作加排他锁，事务完成 锁释放
2. 读－写
客户端2可以对客户端1正在读取的记录进行修改, 而根据锁相关知识, 如果说客户端1在读取记录的时候加了S锁, 那么客户端2是不能加X锁对该记录进行更改的, 所以可以得出结论: 要么是客户端1读取记录的时候没有加S锁, 要么是客户端2更改记录的时候不加任何锁(这样即使客户端1加了S锁,对它这个不加锁的事务也无可奈何)；而在rr下，写操作是加排他锁的，所以只能是第一种情况：读操作不加共享锁（这个是自然的，个人以为不用验证）
3. 通过写－读 验证 读操作不加锁，无视你排他锁
既然写是加排他锁的，
-
接下来你肯定会纳闷 "既然该隔离级别下事务在修改数据的时候加的是x锁, 并且是事务完成后才释放, 那之前的测试客户端2在事务中修改完数据之后, 为什么事务还没完成, 也就是x锁还在, 结果客户端1却能读取到客户端2修改的数据"？这完全不符合排他锁的特性啊(要知道,排他锁会阻塞除当前事务之外的其他事务的读,写操作)
- 其实网上已经有人在sqlserver的官网上找到了相关资料:
ansactions running at the READ UNCOMMITTED level do not issue shared locks to prevent other transactions from modifying data read by the current transaction. READ UNCOMMITTED transactions are also not blocked by exclusive locks that would prevent the current transaction from reading rows that have been modified but not committed by other transactions. When this option is set, it is possible to read uncommitted modifications, which are called dirty reads. Values in the data can be changed and rows can appear or disappear in the data set before the end of the transaction. This option has the same effect as setting NOLOCK on all tables in all SELECT statements in a transaction. This is the least restrictive of the isolation levels.- 翻译翻译, 在思考思考, 其实说的是
在 READ UNCOMMITTED 级别运行的事务不会发出共享锁来防止其他事务修改当前事务读取的数据, 既然不加共享锁了, 那么当前事务所读取的数据自然就可以被其他事务来修改。
而且当前事务要读取其他事务未提交的修改, 也不会被排他锁阻止, 因为排他锁会阻止其他事务再对其锁定的数据加读写锁, **但是可笑的是, 事务在该隔离级别下去读数据的话根本什么锁都不加, 这就让排他锁无法排它了, 因为它连锁都没有**。
这就导致了事务可以读取未提交的修改, 称为脏读。所以可以得出: READ UNCOMMITTED隔离级别下, 读不会加任何锁。而写会加排他锁，并到事务结束之后释放。
观点：排他锁会足足其它事务再对其锁定的数据加读或写的锁，但是不加锁的没办法