shengyu

mysql中锁机制核心是保证数据的一致性以及并发控制。锁机制的实现与存储引擎有关，本文介绍的是INNODB存储引擎的锁机制；其他存储引擎如myISAM和memory等仅支持表锁不支持行锁，不是本文关注的重点。本文介绍mysql数据库提供的锁机制，包括共享锁和排它锁、表锁和行锁、间隙锁和next_key锁。理解本文后，有助于在不同业务场景设计出合理的索引结构。最后介绍死锁的检测和处理方式。

mysql提供了读未提交、读已提交、可重复读、串行化四种隔离级别，默认的隔离界别为可重复读。其中，不可重复度场景下，每次直接读取最新记录(即使事务未提交)；串行化对于所有的读写都加锁，因此，对二者不做过多介绍，MVCC只适用于可重复度和读已提交。mysql的并发事务中存在三种冲突：读-读、读-写、写-写。其中读-读没有冲突，可以同时进行；写-写通过数据库锁实现冲突分离；MVCC解决的是读-写冲突，并尽可能提高数据库性能。

本文涉及的内容较为底层，做了解即可，是以前学习《高性能mysql》和《mysql是怎样运行的》的笔记整理所得。undolog设计的初始目的是保证事务的原子性。mysql的修改操作发生后，如果所在的事务未被提交，如mysql服务或者操作系统发送了异常或执行了回滚等情况，事务的已修改操作需被还原。而还原需记录必要的数据，这些数据就是undolog。

redolog的核心作用是保证数据库的持久性。数据和索引保存在磁盘上，为提高效率读写时需从磁盘将数据加载到内存(Buffer Pool)中，并基于内存进行读写。内存中的数据不稳定，当系统断电或者崩溃时数据会丢失，因此所有修改最终都要刷入磁盘。数据库事务具有持久性，事务提交成功后，无论数据库环境如何(数据库或者操作系统崩溃)，已提交事务涉及的修改都会被保存下来。

binlog(binary log)是mysql的二进制日志，用于顺序记录数据库的逻辑变更。binlog记录DDL和DML等涉及数据库修改的操作，而不会记录Select和show等查询类操作。由于顺序记录了数据库发生的变化，binlog承载了数据库的变化信息，可用于进行数据库数据复制和数据同步、数据恢复、数据审计等。

建议读者站在设计者的角度，思考如何设计InnoDB缓存以中的聚簇索引为例, 查询主键为33的记录:[1] 加载聚簇索引根节点所在的数据页；[2] 使用33与目录(21, 35)依次进行比较，得到子节点信息(地址、表空间、页号);[3] 加载子节点所在的数据页；[4] 使用33与目录(30, 32, 33)依次进行比较，得到叶子节点信息(地址、表空间、页号);[5] 将叶子节点中保存的数据返回;此过程涉及3次IO操作，由于索引和数据存放于磁盘中，3次IO均为磁盘IO，速度较慢；

数据库作为持久层需要从磁盘读写数据，是整个系统的短板，其性能会直接体现在产品性能上。因此数据库的设计和优化再怎么强调也不为过。本文将从数据库设计和查询优化两个角度思考如何提高数据库性能，内容包括数据库范式与表设计、基本字段类型介绍和使用原则、索引设计原则、explain和optimze_trace命令使用介绍、索引失效场景等。本文旨在为读者提供数据库设计指导以及帮助读者提高数据库设计能力。

索引类似字典的目录，用于提高查询速度。字典目录存放单词与页码的映射关系，在目录中根据单词找到页码，根据页码翻到指定页面，得到单词的详细信息。数据以行为单位存放于磁盘，每条行记录对应一个存储地址，索引可以存放数据和存储地址的映射关系，通过索引可快速得到记录的地址；没有索引，查询将退化为数据库遍历。以上是对索引概念的泛泛理解，mysql索引体系的建立也以此为基础，并进行扩展优化。本文介绍mysql索引为后续介绍mysql索引创建原则、索引失效场景以及explain命令的介绍建立基础。

本文将深入探讨InnoDB的底层存储机制，包括行格式、页结构、页目录以及表空间等核心概念。通过全面了解这些基础概念，有助于把握MySQL的存储架构，也为后续深入讨论MySQL的索引原理和查询优化策略奠定了基础。

理解存储引擎，需要建立在数据存储形式以及底层IO的基础上(在后续文章中介绍)。本章仅从特性的角度进行简要说明。如前文介绍，mysql在数据存储层通过插件机制实现，从而支持多种存储引擎，可以在定义表结构时指定使用的存储引擎。常见的存储引擎包括MyIsam、InnoDB、MEMORY、Archive、CSV、Blackhole，其中InnoDB是Mysql8默认的存储引擎。一般而言，MyIsam和InnoDB已满足大部分的业务场景，其他存储引擎作简单了解即可。