多个事务更新同一行数据时，是如何加锁避免脏写的？

脏写是绝对不允许的，那么这个脏写是靠什么防止的呢？说白了，就是靠锁机制，依靠锁机制让多个事务更新一行数据的时候串行化，避免同时更新一行数据。
在MySQL里，假设有一行数据摆在那儿不动，此时有一个事务来了要更新这行数据，这个时候他会先琢磨一下，看看这行数据此时有没有人加锁？一看没人加锁，太好了，说明他是第一个人，捷足先登了。
此时这个事务就会创建一个锁，里面包含了自己的trx_id和等待状态，然后把锁跟这行数据关联在一起。同时，更新一行数据必须把他所在的数据页从磁盘文件里读取到缓存页里来才能更新的，所以说，此时这行数据和关联的锁数据结构，都是在内存里的。因为事务A给那行数据加了锁，所以此时就可以说那行数据已经被加锁了。那么既然被加锁了，此时就不能再让别人访问了！
现在呢，有另外一个事务B过来了，这个事务B就也想更新那行数据，此时就会检查一下，当前这行数据有没有别人加锁。然而他一下子发现，真是糟糕啊，事务A这家伙太不地道了，居然抢先给这行数据加锁了，这怎么办呢？事务B这个时候一想，那行，我也加个锁，然后等着排队不就得了，这个时候事务B也会生成一个锁数据结构，里面有他的trx_id，还有自己的等待状态，但是他因为是在排队等待，所以他的等待状态就是true了，意思是我在等着呢。
接着事务A这个时候更新完了数据，就会把自己的锁给释放掉了。锁一旦释放了，他就会去找，此时还有没有别人也对这行数据加锁了呢？他会发现事务B也加锁了。于是这个时候，就会把事务B的锁里的等待状态修改为false，然后唤醒事务B继续执行，此时事务B就获取到锁了。
上述就是MySQL中锁机制的一个最基本的原理，其实是跟Java里的锁机制，思路是完全类似的，从这种简单的锁里可以引申出很多其他的概念，比如读写锁，共享锁，独占锁，公平锁，非公平锁，等等。Java里的锁，也同样具备这些锁的概念。

共享锁和独占锁到底是什么？

那么在这多个事务运行的时候，他们加的是什么锁呢？其实是X锁，也就是Exclude独占锁，当有一个事务加了独占锁之后，此时其他事务再要更新这行数据，都是要加独占锁的，但是只能生成独占锁在后面等待。
当有人在更新数据的时候，其他的事务可以读取这行数据吗？默认情况下需要加锁吗？答案是：不用。因为默认情况下，有人在更新数据的时候，然后你要去读取这行数据，直接默认就是开启mvcc机制的。也就是说，此时对一行数据的读和写两个操作默认是不会加锁互斥的，因为MySQL设计mvcc机制就是为了解决这个问题，避免频繁加锁互斥。此时你读取数据，完全可以根据你的ReadView，去在undo log版本链条里找一个你能读取的版本，完全不用去顾虑别人在不在更新。就算你真的等他更新完毕了还提交了，基于mvcc机制你也读不到他更新的值啊！因为ReadView机制是不允许的，所以你默认情况下的读，完全不需要加锁，不需要去care其他事务的更新加锁问题，直接基于mvcc机制读某个快照就可以了。
那么假设万一要是你在执行查询操作的时候，就是想要加锁呢？那也是ok的，MySQL首先支持一种共享锁，就是S锁，这个共享锁的语法如下：select from table lock in share mode，你在一个查询语句后面加上lock in share mode，意思就是查询的时候对一行数据加共享锁。
如果此时有别的事务在更新这行数据，已经加了独占锁了，此时你的共享锁能加吗？当然不行了，共享锁和独占锁是互斥的！此时你这个查询就只能等着了。那么如果你先加了共享锁，然后别人来更新要加独占锁行吗？当然不行了，此时锁是互斥的，他只能等待。
那么如果你在加共享锁的时候，别人也加共享锁呢？此时是可以的，你们俩都是可以加共享锁的，共享锁和共享锁是不会互斥的。所以这里可以先看出一个规律，就是更新数据的时候必然加独占锁，独占锁和独占锁是互斥的，此时别人不能更新；但是此时你要查询，默认是不加锁的，走mvcc机制读快照版本，但是你查询是可以手动加共享锁的，共享锁和独占锁是互斥的，但是共享锁和共享锁是不互斥的，如下规律。
不过说实话，一般开发业务系统的时候，其实你查询主动加共享锁，这种情况较为少见，数据库的行锁是实用功能，但是一般不会在数据库层面做复杂的手动加锁操作，反而会用基于redis/zookeeper的分布式锁来控制业务系统的锁逻辑。
另外就是，查询操作还能加互斥锁，他的方法是：select from table for update。这个意思就是，我查出来数据以后还要更新，此时我加独占锁了，其他闲杂人等，都不要更新这个数据了。一旦你查询的时候加了独占锁，此时在你事务提交之前，任何人都不能更新数据了，只能你在本事务里更新数据，等你提交了，别人再更新数据。

在数据库里，哪些操作会导致在表级别加锁呢？

在多个事务并发更新数据的时候，都是要在行级别加独占锁的，这就是行锁，独占锁都是互斥的，所以不可能发生脏写问题，一个事务提交了才会释放自己的独占锁，唤醒下一个事务执行。如果你此时去读取别的事务在更新的数据，有两种可能：第一种可能是基于mvcc机制进行事务隔离，读取快照版本，这是比较常见的；第二种可能是查询的同时基于特殊语法去加独占锁或者共享锁。如果你查询的时候加独占锁，那么跟其他更新数据的事务加的独占锁都是互斥的；如果你查询的时候加共享锁，那么跟其他查询加的共享锁是不互斥的，但是跟其他事务更新数据就加的独占锁是互斥的，跟其他查询加的独占锁也是互斥的。
在数据库里，你不光可以通过查询中的特殊语法加行锁，比如lock in share mode、for update等等，还可以通过一些方式在表级别去加锁。有些人可能会以为当你执行增删改的时候默认加行锁，然后执行DDL语句的时候，比如alter table之类的语句，会默认在表级别加表锁。这么说也不太正确，但是也有一定的道理，因为确实你执行DDL的时候，会阻塞所有增删改操作；执行增删改的时候，会阻塞DDL操作。
但这是通过MySQL通用的元数据锁实现的，也就是Metadata Locks，但这还不是表锁的概念。因为表锁其实是InnoDB存储引擎的概念，InnoDB存储引擎提供了自己的表级锁，跟这里DDL语句用的元数据锁还不是一个概念。只不过DDL语句和增删改操作，确实是互斥的。

表锁和行锁互相之间的关系以及互斥规则是什么呢？

MySQL里是如何加表锁的。这个MySQL的表锁，其实是极为鸡肋的一个东西，几乎一般很少会用到，表锁分为两种，一种就是表锁，一种是表级的意向锁。
首先说表锁，这个表锁，可以用如下语法来加：
LOCK TABLES xxx READ：这是加表级共享锁
LOCK TABLES xxx WRITE：这是加表级独占锁
其实一般来讲，几乎没人会用这两个语法去加表锁，这不是纯属没事儿找事儿么，所以才说表锁特别的鸡肋。
还有就是有另外两个情况会加表级锁。如果有事务在表里执行增删改操作，那在行级会加独占锁，此时其实同时会在表级加一个意向独占锁；如果有事务在表里执行查询操作，那么会在表级加一个意向共享锁。
其实平时我们操作数据库，比较常见的两种表锁，反而是更新和查询操作加的意向独占锁和意向共享锁，但是这个意向独占锁和意向共享锁，大家暂时可以当他是透明的就可以了，因为两种意向锁根本不会互斥。为啥呢？因为假设有一个事务要在表里更新id=10的一行数据，在表上加了一个意向独占锁，此时另外一个事务要在表里更新id=20的一行数据，也会在表上加一个意向独占锁，你觉得这两把锁应该互斥吗？明显是不应该互斥的啊，因为他们俩更新的都是表里不同的数据，你让他们俩在表上加的意向独占锁互斥干什么呢？所以意向锁之间是根本不会互斥的。
同理，假设一个事务要更新表里的数据，在表级加了一个意向独占锁，另外一个事务要在表里读取数据，在表级加了一个意向共享锁，此时你觉得表级的意向独占锁和意向共享锁应该互斥吗？当然不应该了！一个人要更新数据，一个人要读取数据，俩人在表上加的意向锁，凭什么要互斥？没天理啊！
所以说，这个所谓的表级的意向独占锁和意向共享锁，似乎是跟脱了裤子放屁一样，多此一举？但是我们接下来就要看看，手动加表级共享锁和独占锁，以及更新和查询的时候自动在表级加的意向共享锁和意向独占锁，他们之间反而是有一定的互斥关系，关系如下表所示。
上面表格说的是在表上面手动加的独占锁和共享锁，以及更新数据和查询数据默认自动加的意向独占锁和意向共享锁，他们互相之间的互斥关系。其实更新数据自动加的表级意向独占锁，会跟你用 LOCK TABLES xxx WRITE 手动加的表级独占锁是互斥的，所以说，假设你手动加了表级独占锁，此时任何人都不能执行更新操作了！或者你用LOCK TABLES xxx READ手动加了表级共享锁，此时任何人也不能执行更新操作了，因为更新就要加意向独占锁，此时是跟你手动加的表级共享锁，是互斥的！其实一般来说，根本就不会手动加表级锁，所以一般来说读写操作自动加的表级意向锁，互相之间绝对不会互斥。