死锁

死锁是指两个或者多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环的现象，多个事务同时锁定同一资源时，也会产生死锁。

比如：

事务开始

Asession：

1更新A表id1的字段

2更新A表id2的字段

Bsession：

1更新B表id2的字段

2更新A表id1的字段

ABsession都开启事务后同时执行了1，那么id1，2都因为更新是排它锁，锁住了

都会去执行第二条sql，就执行不成功了。互相没有释放锁。

mysql会自己处理。

把持有行级锁最少的那一条事务回滚最后一条

如果行锁个数相同，回滚最后尝试获取锁的事务。

事务日志

事务可以回滚和提交是因为事务日志

通过事务日志实现回滚

在为提交之前没有存在数据库文件上

写日志的操作是磁盘上一小块区域内的顺序I/O，而不像随机I/O需要在磁盘的多个地方移动磁头，所以采用事务日志的方式相对来说要快得多。事务日志持久以后，内存中被修改的数据在后台可以慢慢的刷回到磁盘。目前大多数存储引擎都是这样实现的，我们通常称为预写式日志，修改数据需要些两次磁盘。

如果数据的修改已经记录到事务日志并持久化，但数据本身还没有写回磁盘，此时系统崩溃，存储引擎在重启时能够自动恢复这部分修改的数据。

多版本并发控制（MVCC）

MySQL中大多数事务型存储引擎实现都不是简单的行级锁。基于提升并发性能考虑，他们一般都同时实现了多版本并发控制（Multi-Version Concurrency Control，MVCC）.

Oracle等其他数据库也实现了MVCC，但是各自实现机制不尽相同，以为MVCC没有一个统一的实现标准。

可以认为MVCC就是行级锁的一个变种，但是他在很多情况下避免了加锁操作。

MVCC是通过保存数据在某个时间点的快照来实现的。也就是说，不管一个事务需要执行多长时间，每个事物看到的数据都是一致的。

根据事务开始时间的不同，不同事务对同一张表，在同一个时刻看到的数据可能是不一样的。

MVCC有很多种版本的实现，在InnoDB引擎下MVCC是通过在每行记录后面保存两个隐藏的列来实现的。

一列保存了行的创建时间（版本），一列保存了行的删除时间（版本）。存储的并不是实际的时间值，而是系统版本号。

每开始一个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询中每行记录的版本号进行比较。

比如在REPEATABLE TABLE隔离级别下：

Insert: 为新插入的每一行记录保存当前系统版本号作为行版本号。

Delete：为删除的每一行保存当前系统版本号作为删除版本号。

Update：插入一行新的记录，保存当前系统版本号作为行版本号，同时保存当前系统版本号为原来的行作为删除版本号。

Select：

1.只查找版本号早于当前事务版本的数据行（也就是，行的系统版本号小于或等于事务的系统版本号）；这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或修改过的。

2.行的删除版本号要么没有，要么大于当前事务版本号。这样可以确保事务读取到的行，在事务开始之前未被删除。

MVCC只在REPEATABLE READ和READ COMMITTED两个隔离级别下工作。因为READ UNCOMMITTED总是读取最新的数据行，而不是符合当前事务版本的数据行。

而SERIALIZABLE则会对所有读取的行都加锁。

注意：需要周期性的整理，来真实的删除老的、过期的数据。

InnoDB 有预读

根据局部性原理预读一部分数据

数据库优化方面

1 硬件优化

2 系统配置优化

3 数据库表结构优化

4 SQL索引优化