MySQL的表级锁、行级锁、排它锁和共享锁

先说下事务是什么，因为我们业务是比较复杂的，不可能一个sql就能解决的，涉及多个sql就组成一个事务。事务就是一组sql共同执行，要么完全成功，要么完全失败，不能出现部分成功或者部分失败的情况。一个事务有ACID特性（可以参考：事务的ACID特性和MySQL事务的隔离级别）：

原子性：要么全部成功，要么全部失败，这样才能保证事务的一致性；
一致性：比如银行的转账，扣除一个人的钱肯定要给另一个人加钱，不能光扣除不加，这样业务就存在问题，数据的一致性就破坏了；
持久性：当我们数据commit以后，数据是先写到缓存当中，缓存中的数据还是要慢慢花时间往磁盘上写，如果此时停电了、宕机或者重启了，我们有redo log重做日志来保证数据库的持久性；
隔离性：这块可以说下事务为什么要有隔离性，因为事务要允许并发执行，一个业务涉及了很多事务，而我们后台往往有很多业务，要能够让他们并发执行，如果所有的事务都是串行执行的话，那这样我们写多线程程序只有一个线程来做事情，这样效率很低。所以事务要并发执行，但是并发执行涉及了一些问题：事务的安全性&一致性和并发的效率问题，我们以这两个东西为参考点，才得到了MySQL不同等级的并发/隔离，如果事务并发执行时我们完全不隔离的话，就可能会出现脏读（事务B读到了事务A还未提交的数据然后，然后用事务A未提交的数据去做计算，得到了很多其他的结果，然后事务A又把那个数据rollback掉，那么事务B计算出来的都是有问题的数据，脏读一定会出现问题）、不可重复读（以同样的条件去一个数据，然后再次去查询的时候发现数据的值有所改变，当然不可重复读也不一定会有问题，有些业务场景下是允许的，这和业务上数据的安全性和一致性是否严格有关）和幻读（在事务中按照同样的条件前后两次查询的结果数据量不同）这些问题。那么我们为了解决事务并发执行遇到的问题就给出了事务的隔离级别：
- 串行化，串行化完全用锁来实现，通过锁给所有事务排序，按顺序执行，这样做数据的安全性高但并发的效率很低，一般我们不会这样做的。
- 未提交读，对于我们写的多线程程序来说，对于临界区代码段没有做任何的并发控制，虽然并发性高但数据安全性很低，未提交读还允许脏读的存在，这是有问题的所以绝对不会使用未提交读。
  串行化和未提交读在实际项目中是不会用到的，一般数据库引擎默认工作在已提交读和可重复读，这两个隔离级别就结合了数据的安全性&一致性和数据的并发效率，这两个是由MVCC多版本并发控制机制实现的。
- 已提交读，oracle默认工作级别。不允许读取未commit的数据，这个级别仍然允许不可重复读和虚读产生。
- 可重复读，MySQL默认工作级别。保证事务再次读取是依然得到相同的数据，部分解决了虚读，但虚读是仍然会出现的
  
  注意：
1. 事务隔离级别越高，为避免冲突所花费的性能也就越多，即效率低。
2. 在“可重复读”级别，实际上可以解决部分的虚读问题，但是不能防止update更新产生的虚读问题，要禁止虚读产生，还是需要设置串行化隔离级别。
事务隔离级别的实现原理：锁+MVCC。串行化底层实现原理是锁，锁有共享锁、排它锁、意向共享锁、意向排它锁、间隙锁和死锁，InnoDB的已提交读和可重复读的底层实现原理：MVCC（多版本并发控制），MVCC提供了一种并发读取方式，包括快照读（同一份数据会有多个版本）、当前读、undo log和redo log。MVCC是已提交读和可重复读的原理，锁是串行化的原理