如果数据库中的事务操作，都是串行的，可以保证事务在执行过程中不会出现异常，但带来的是性能问题。事务并行执行，带来了其他死锁，更新丢失等一系列问题。
事务ACID
- 为什么需要事务： 事务是为了保障用户的数据操作是绝对安全的。比如在个人银行卡账户余额，我们期望它的操作是稳定准确且绝对安全的。
- ACID是数据库在写入或更新数据时，为保证事务是正确可靠的，所必须具备的四种特性；原子性（atomicity）、一致性（consistency）、隔离性（isolation）、持久性（durability）。
- 原子性（atomicity): 一个事务（transaction）中的所有操作，或者全部完成，或者全部未完成，不会结束在中间的某个的某个环节。事务在中间发生错误时，会回滚到执行前的状态。在mysql中，主要有InnoDB引擎中的undo log来维护。
- 一致性（consistency）：在事务开始和结束后，数据库的完整性没有被破坏。
- 隔离性（isolation）：数据库允许多个事务能够同时对其数据进行读写和修改，隔离性可以防止多个事务并发执行时由于交叉执行而导致的数据不一致性问题，简而言之就是防止其他事务对本事务操作产生影响。 事务的隔离级别一般分为，读未提交（read uncommitted）、读已提交（read committed）、可重复读（repeatable read）、串行化（serializable）。
- 持久性（durability）：事务结束后，对事务的修改是永久性的，即使系统故障，数据也不会丢失。 mysql中主要通过redo log来维护。
不同隔离级别产生的影响
- 读未提交： 允许读取未提交额数据，会发生脏读、不可重复读、幻读。
- 读已提交： 允许读取已经提交的数据，不会发生脏读，会发生不可重复读，幻读。
- 可重复读：一个事务执行中看到的数据，总是跟这个事务启动时看到的数据是一致的。不会发生脏读，不可重复读，会发生幻读。
- 串行化：对于同一行记录操作，事务之间是串行化操作。不存在脏读，不可重复读，幻读问题。
锁机制
锁一般分为两类：
- 共享锁（Share Locks）：简称S锁，事务对一条记录进行读操作时，先获取共享锁。
- 排它锁（Exclusive Locks）：简称X锁，事务对一条记录进行写操作时，先获取排他锁。
通过锁机制可以帮我们维护高并发环境下数据的一致性和数据安全。
一般数据的操作场景包括 读-读、读-写、写-写场景。通过锁机制可以帮助我们解决读-读，写-写等问题，为了提高读-写场景的性能，mysql使用了mvcc机制。
mvcc
mvcc：多版本并发控制，侧重优化读-写场景，可以解决写操作时，堵塞读操作。
innodb中，每次数据更新的时候，都会生成一个数据版本号，同时旧的版本的数据也会保留，版本之间通过undo log 恢复数据。因为多版本数据的存在，在并发读取数据时，可以不因为写操作而阻塞。
innodb中，在可重复读场景下，为了避免幻读问题，innodb引擎采取了mvcc+间隙锁的方式来解决此问题。
MVCC并不是万灵药。大量的业务问题的关键点在于，你在提交一个事务那一刹那，你提交事务的所有修改依赖的读取是否都还有效。对于这种场景，InnoDB中可以使用select ... for update手工加锁，或用Serializable隔离级别
大事务
- 大事务： 事务运行时间较长的一类事务。
- 产生原因：
- 事务操作的数据量较大
- 存在锁竞争
- 事务中存在一些耗时工作
- 影响：
- 耗尽数据库连接池
- 锁定过多数据，造成大量阻塞，超时
- 执行时间长，造成主从延迟
- undo log日志膨胀
在实际操作过程中，为了避免大事务，我们在一次事务中，尽量减少一次操作的数据量，避免一些不必要操作，在数据库操作过程中，减少业务逻辑的处理。
参考引用：
https://juejin.cn/post/6844904096378404872
https://segmentfault.com/a/1190000038534692
https://segmentfault.com/a/1190000023273980
