MySQL之InnoDB存储引擎 - 读书笔记
1. MySQL 的存储引擎
MySQL 数据库的一大特色是有插件式存储引擎概念。日常使用频率最高的两种存储引擎：
InnoDB 存储引擎支持事务，其特点是行锁设计、支持外键、非锁定读（默认读取操作不会产生锁）。1.2.x 开始支持全文索引。数据存储方面，InnoDB (即指 InnoDB 存储引擎) 采用了聚集 （clustered）的方式，每张表的存储都是按逐渐的顺序进行存放。（如果没有显式定义主键， InnoDB 会为每行生成一个6字节的 ROWID，并以此作为主键）
MyISAM存储引擎不支持事务、表锁设计，支持全文索引。MyISAM另一个与众不同的地方是它的缓冲池只缓存索引文件，而不缓存数据文件。数据存储方面，MyISAM表由 MYD 和 MYI 组成，分别用来存放数据文件和索引文件。
2. InnoDB 存储引擎
InnoDB 存储引擎是 Mysql 数据库 OLTP ( Online Transaction Processing 在线事务处理 ) 应用中使用最广泛的存储引擎。特点前面已经提过，现在来看看 InnoDB 的体系架构。
2.1 InnoDB 体系架构
2.2.1 后台线程
后台线程的主要作用是刷新内存池中的数据（保持最新）。此外，还将已修改的文件同步到磁盘文件，同时保证在数据库发生异常情况时 InnoDB 能恢复到正常运行状态。
InnoDB是多线程的模型，所以有不同的后台线程，用来处理不同的任务。包含如下线程：
- Master Thread 是一个非常核心的后台线程，主要负责将缓冲池的数据异步刷新到磁盘，以保证数据的一致性。
- IO Thread 的主要工作主要是负责IO请求的回调处理，因为InnoDB 中大量使用了AIO（Async IO）来处理写请求。有四类 IO Thread, 分别是 write、read、insert buffer 和 log。
- Purge Thread 用来回收已经使用并分配的 Undo 页（事务提交后可能不再需要的 undolog）。
- 1.2.x 版本新引入的 Page Cleaner Thread 用来将脏页的刷新操作都放到新线程进行。
2.2.2 内存
内存池负责如下工作：1. 维护所有进程/线程所需（访问）的内部数据结构；2. 缓存磁盘上的数据，以便快速地读取；3. 重做日志缓冲；……
具体如下：
-
缓冲池
InnoDB存储引擎是基于磁盘存储的，记录按照页的方式进行管理。可将其视为基于磁盘的数据库系统。
缓冲池就是一块内存区域，通过内存的速度来弥补磁盘速度较慢对数据库性能的影响。缓冲池的设计目的是为了协调CPU速度与磁盘速度的鸿沟。
缓冲池缓存的数据页类型有：数据页、索引页、undo页、插入缓冲、自适应哈希索引、锁信息、数据字典信息等，如下图：
-
LRU List、Free List 和 Flush List
数据库的缓冲池是用 LRU (Latest Recent Used, 最近最少使用)算法来管理的。LRU是一种缓存置换算法，即在缓存有限的情况下，如果有新的数据需要加载进缓存，则需要将最不可能被继续访问的缓存剔除掉 。InnoDB 存储引擎的缓冲池管理算法是用优化过的LRU管理的。（题外话：Redis达到maxmemory后的回收策略中的LRU算法也不是朴素的算法，采用近似LRU算法，只取出一小部分数据并根据访问时间丢掉老数据）。
如上草图所示，InnoDB在 LRU List (LRU 列表) 中加入了 midpoint 位置（百分比, 通过innodb_old_blocks_pct 设置，默认37），将缓冲池 LRU 列表分为new&old 列表，new 列表存放热点数据（也称new列表这端为热端），新读取的页放入尾端的 old 列表（过多久会加入到热端，通过一个 innodb_old_blocks_time 时间来管理 , 默认0）。可使用
show variables like 'innodb_old_blocks_%';查看 innodb_old_blocks_pct 和 innodb_old_blocks_time 值：
以上是LRU List 的概念，在数据刚刚启动时，没有任何的页，LRU List 是空的。页都放在 Free List 中，当需要在缓冲池分页时，才将Free List 中的页放入 LRU List。
可以运行命令
show engine innodb status;查看缓冲池大小、LRU列表大小、Free列表大小、页移动到热端的次数。忍不住贴出原文
下面为笔者查看时的数据 之前设置了缓冲池大小700M set global innodb_buffer_pool_size=734003200; 查看时：show variables like 'innodb_buffer_pool_size'; 结果缓冲池大小是 738197504 多了4M数据（这4M应该是表的空间暂时不深究）。 ===================================== 2019-11-13 14:10:58 0x174b0 INNODB MONITOR OUTPUT ===================================== Per second averages calculated from the last 32 seconds ...... ---------------------- BUFFER POOL AND MEMORY ---------------------- Total large memory allocated 755499008 Dictionary memory allocated 361836 Buffer pool size 45056 # 缓冲池大小（页为单位） 45056*16k=738197504 bytes 与上面的缓冲池大小一致 Free buffers 0 Database pages 37689 # LRU LIST 页大小 Old database pages 13892 Modified db pages 0 # 脏页大小 Pending reads 0 Pending writes: LRU 0, flush list 0, single page 0 Pages made young 26230, not young 0 0.00 youngs/s, 0.00 non-youngs/s Pages read 8525, created 43072, written 49077 0.00 reads/s, 0.00 creates/s, 0.00 writes/s Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000 如果在记录周期（当前为32秒）内，没有使用到缓存，则上面 BUFFER POOL HIT RATE 这一行会是：No buffer pool page gets since the last printout Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s LRU len: 37689, unzip_LRU len: 0 I/O sum[0]:cur[0], unzip sum[0]:cur[0]在LRU List 需要中的页被修改后，称该页为脏页(dirty page)（缓存和磁盘数据不一致）。这时数个据库通过CHECKPOINT 机制将脏页刷新回磁盘，此时Flush List中的页为脏页列表。脏页存在于LRU 列表和Flush 列表，LRU 列表用来管理缓冲池中页的可用性，Flush 列表用来将页刷新回磁盘。
-
重做日志缓冲 （redo log buffer）
重做日志的作用是确保事务的持久性。防止在故障发生时，有脏页未写入磁盘（重启MySQL服务时，根据redo log文件恢复数据）。重做日志缓冲区是放重做日志信息的地方，下面三种情况会将重做日志缓冲中的内容刷新到磁盘的重做文件中：
Master Thread 每秒将重做日志缓冲刷新到重做日志文件；
每个事务提交时会将重做日志缓冲刷新到重做日志文件；
当重做日志缓冲剩余空间小于1/2时，重做日志缓冲刷新到重做日志文件。
-
额外的内存池
不应该被忽略。就像指针指向的内容需要内存，但是指针本身也需要内存一样。缓冲池的帧缓冲和缓冲控制对象等都需要内存，就存在额外的内存池中。
2.2 Checkpoint（检查点）技术
页的操作首先都是在缓冲池中完成的。如果一条 DML 语句（如 Update 或 Delete ）改变了页中的记录，那么此时页是脏页（即缓冲池中的页的版本要比磁盘的新），数据库需要将新版本的页从缓冲池刷新到磁盘。
Checkpoint 技术的目的：
- 缩短数据库的恢复时间
- 缓冲池不够用时，将脏页刷新到磁盘
- 重做日志不可用时，刷新脏页
具体的 Checkpoint 有几种类型还有触发 Fuzzy Checkpoint 的几种情况，作者都总结的清晰且简洁，需要的可以去查书。
2.3 命令
-- MySQL 版本
select version();
-- InnoDB 版本
show variables like 'innodb_version';
-- IO Thread
show variables like 'innodb_%io_threads';
-- InnoDB status, 可以看到 IO thread 信息
show engine innodb status;
-- purge thread, 回收已经使用并分配的Undo页
show variables like 'innodb_purge%';
-- 缓冲池配置大小
show variables like 'innodb_buffer_pool_size';
-- 缓冲区实例个数
show variables like 'innodb_buffer_pool_instances';
-- midpoint和加入热端的时间
show variables like 'innodb_old_blocks_%';
关于存储引擎这章，还讲了 InnoDB 关键特性（插入缓冲、两次写、自适应哈希索引、异步IO 和 刷新邻接页），以及启动和关闭 MySQL 时的一些配置参数对 InnoDB（full purge、数据恢复、插入缓冲合并等） 的影响。
3. 表
关系型数据库模型的核心是：表是关于特定实体的数据集合。本章从InnoDB的表的逻辑存储开始介绍，然后重点分析表的物理存储特征（即数据在表中是如何组织和存储的）。
3.1 索引组织表
存储方式是根据主键顺序组织存放的表称为索引组织表(index organized table)。
在 InnoDB 表中，每张表都有个主键 (Primary Key)，如果在创建表时没有显式的定义主键，首先会判断表中是否有非空的唯一索引 (Unique NOT NULL)，如果有则该列为主键，否则，InnoDB 会自动创建一个6字节大小的指针（并以此为主键）。
当表中有多个非空唯一索引时，InnoDB 将选择建表时第一个定义的非空唯一索引为主键。（这里需要注意，主键的选择是根据定义索引的顺序而不是建表字段的顺序）。看例子：
create table z(
a int not null,
b int null,
c int not null,
d int not null,
unique key(b), unique key(d), unique key(c)
)ENGINE=InnoDB;
insert into z select 1,2,3,4;
select *, _rowid from z;
请看上面例子。唯一索引有三个，b、d 和 c，因为b不是非空的，所以跳过，选择 d 做主键。可以通过查询 _rowid 来观察隐藏主键。
显示创建表的语句：
show create table table_name;
3.2 InnoDB 逻辑存储结构
上图是 InnoDB 的逻辑存储结构，所有数据都放在表空间中，表空间(tablespace)由段(segment)、区(extent)、页(page)/块(block)组成。图中可看到页中有行(row)记录。
InnoDB 中常见的段有数据、索引、回滚段等。
页是 InnoDB 磁盘管理的最小单位，默认每个页大小是 16KB（从1.2.xa版本开始，可以通过参数 innodb_page_size 设置页大小为4、8、16K）。区是由连续页组成的空间，在任何时候每个区的大小都为1MB（所以当页大小为64、16、8、4K时，每个区对应页的数量是64、128、256、512）。常见的页类型有：数据页、Undo页、系统页、事务数据页等。
InnoDB 是面向行的，即数据是按行进行存放的。每页存放数据有硬性规定，最多允许 16KB/2-200=7922 行记录。
3.3 InnoDB 行记录格式
InnoDB 提供了 Compact 和 Redundant 两种格式来存放行记录数据（Redundant 是为了兼容之前版本而保留的）。可以通过行记录的组织规则来读取其中的记录。
3.3.1 行溢出数据
首先考虑一个问题：MySQL 数据库的 VARCHAR 类型最多可以存放 65535 字节数据吗？做个试验发现只可以存储 65532 字节数据
create table z2(
vc_1 varchar(10) null
)ENGINE=InnoDB CHARSET=utf8mb4 ROW_FORMAT=COMPACT;
alter table z2 modify column `vc_1` varchar(16383);
create table z3(
vc_1 varchar(10) null
)ENGINE=InnoDB CHARSET=latin1 ROW_FORMAT=COMPACT;
alter table z3 modify column `vc_1` varchar(65532);
-- show table status;
新建两个表，只有一个 varchar 字段（varchar后指定的是存储字符串长度而不是字节长度），因为 charset 不同，存储的字符长度不同（但总字节长度一样，都为65532）。z2 表中，utf8mb4每个字符占用4个字节，16383*4=65532。再设置的大一点就会报错了，所以 varchar 最多存储 65532 字节数据。
针对 65532 字节的数据，InnoDB 的页仅为 16KB(16384 字节)，溢出的数据会怎么存储呢？答案是表空间文件只存储了字符串的部分前缀，然后是一个偏移地址，指向一些 BLOB页（实际存放数据的地方）。原作者在这里演示的时候，前缀存放了768字节的数据，还有其他四个BLOB页。
3.3.2 Compact 行记录格式
Compact 行记录是在 MySQL5.0 中引入的。
Redundant 行记录格式略。主要为了兼容MySQL5.0版本之前的页格式。
InnoDB 1.0.x 版本开始引入新的文件格式（即页格式）。以前的 Compact 和 Redundant 格式称为 Anteelope 文件格式，新的文件格式称为 Barracuda 文件格式（拥有两种新的行记录格式：Compressed 和 Dynamic）。新的格式采用了完全的行溢出方式，在数据页只存放 20 字节指针，实际的数据都存放在 Off Page 中。之前的两种格式则会存放 768 个前缀字节。
3.4 约束
3.4.1 数据完整性
关系型数据库系统本身能保证存储数据的完整性（相对的，文件系统需要在程序端进行控制），一般来说，数据完整性有以下三种形式：
- 实体完整性保证表中有一个主键
- InnoDB 中可以通过定义 Primary Key 或 Unique Key 约束来保证实体的完整性
- 用户编写触发器来保证数据完整性
InnoDB 提供了以下几种约束：
- Primary Key
- Unique Key
- Foreign Key
- Default
- NOT NULL
3.4.2 约束的创建和查找
约束创建可以在建表时定义约束，或者利用 ALTER TABLE 命令来创建约束。对 Unique Key 的约束，用户还可以通过命令 CREATE UNIQUE INDEX 来建立约束。
对于主键约束而言，其默认约束名为PRIMARY；而对于 Unique Key 约束而言，默认约束名和列名一样，当然也可以指定 Unique Key 约束的名字；Foreign Key 约束有一个系统生成的默认名称。
Primary Key & Unique Key
创建一个表，含有一个主键（Primary Key）约束和一个唯一键（Unique Key）约束。并查询约束信息：
CREATE TABLE `constraint_test` (
id INT,
username VARCHAR (20),
id_card CHAR (10),
PRIMARY KEY (id),
UNIQUE KEY (username)
);
SELECT
constraint_name, constraint_type
FROM
information_schema.TABLE_CONSTRAINTS
WHERE
table_schema = "test_innodb" AND table_name = "constraint_test";
-- 结果
+-----------------+-----------------+
| constraint_name | constraint_type |
+-----------------+-----------------+
| PRIMARY | PRIMARY KEY |
| username | UNIQUE |
+-----------------+-----------------+
-- 也可以使用 ALTER TABLE 来新增唯一约束：
ALTER TABLE `constraint_test` ADD UNIQUE KEY uk_id_card(id_card);
Foreign Key
为了建立外键约束，需要另一张表：
-- px 表的 u_id 字段关联 constraint_test 表的 id 字段
CREATE TABLE `px` (
id INT,
u_id INT,
PRIMARY KEY (id),
FOREIGN KEY (u_id) REFERENCES constraint_test(id)
)ENGINE=InnoDB;
-- 查看约束信息
SELECT
constraint_name, constraint_type
FROM
information_schema.TABLE_CONSTRAINTS
WHERE
table_schema = "test_innodb" AND table_name = "px";
+-----------------+-----------------+
| constraint_name | constraint_type |
+-----------------+-----------------+
| PRIMARY | PRIMARY KEY |
| px_ibfk_1 | FOREIGN KEY |
+-----------------+-----------------+
可以看到约束名是 pk_ibfk_1，系统自动生成的，如果需要手动指定名称，创建外键时可以用
CREATE TABLE `px` (
id INT,
u_id INT,
PRIMARY KEY (id),
CONSTRAINT fk_uid FOREIGN KEY (u_id) REFERENCES constraint_test(id)
)ENGINE=InnoDB;
-- 再次查看约束信息
+-----------------+-----------------+
| constraint_name | constraint_type |
+-----------------+-----------------+
| PRIMARY | PRIMARY KEY |
| fk_uid | FOREIGN KEY |
+-----------------+-----------------+
-- 还可以通过 REFERENTIAL_CONSTRAINTS 表查看外键的详细信息
select * from information_schema.REFERENTIAL_CONSTRAINTS where constraint_schema='test_innodb'\G;
-- 输出
*************************** 1. row ***************************
CONSTRAINT_CATALOG: def
CONSTRAINT_SCHEMA: test_innodb
CONSTRAINT_NAME: fk_uid
UNIQUE_CONSTRAINT_CATALOG: def
UNIQUE_CONSTRAINT_SCHEMA: test_innodb
UNIQUE_CONSTRAINT_NAME: PRIMARY
MATCH_OPTION: NONE
UPDATE_RULE: RESTRICT
DELETE_RULE: RESTRICT
TABLE_NAME: px
REFERENCED_TABLE_NAME: constraint_test
疑惑
原书作者在这节创建外键的时候，把主键外键放到了一张表上，也是可以创建成功的：
CREATE TABLE `p` (
id INT,
u_id INT,
PRIMARY KEY (id),
FOREIGN KEY (u_id) REFERENCES p(id)
)ENGINE=InnoDB;
笔者之前一直没有想过把外键放到一张表上（真是不爱思考），说起建立外键约束只是想到关联另外一张表的字段，所以这里一张表本身的字段也可以做外键，那这种特性可以干什么呢？
就具体到上面这个表，id是唯一主键，u_id是外键，关联到主键id上。它们的取值范围是下面这样：
第一行的元素id和u_id都是一样，不然都存不进去。然后第二行对于id是个新元素，对于uid是所有的id集合都可以取。我好像看到了造物主的清单。
3.4.3 约束和索引的区别
当用户创建了一个唯一索引就创建了一个唯一的约束。但是约束和索引的概念不同，约束是一个逻辑概念，用来保证数据的完整性；而索引是一个数据结构，即有逻辑的概念，在数据库中还代表着物理存储的方式。
3.4.4 对错误数据的约束
MySQL数据库允许非法的或不正确的插入或更新，又或者可以在数据库内部转换为一个合法的值。如向 NOT NULL 的字段插入一个 NULL 值，MySQL 数据库会将其转为0再插入；向Date格式插入一个非法值，会转为默认值 0000-00-00。
这时，可以设置 sql_mode 包含 STRICT_TRANS_TABLES开启严格模式，用来对输入值进行约束。
# 创建表
create table error_data_district(
id int NOT NULL,
data Date NOT NULL
);
# 添加数据
insert into error_data_district select NULL,'2019-02-30';
# 查看模式
select @@sql_mode;
# 删除严格模式
set sql_mode = (select replace(@@sql_mode, 'STRICT_TRANS_TABLES', ''))
# 添加严格模式
set sql_mode = (select concat(@@sql_mode, ',STRICT_TRANS_TABLES'))
3.4.5 ENUM和SET约束
通过 ENUM 和 SET 类型可以约束数据值。ENUM（枚举） 存储取值范围内的单选值，SET 存储多选值。
3.4.6 触发器和约束
完整性约束通常也可以使用触发器来实现。触发器的作用是在执行 INSERT、DELETE 和 UPDATE 命令 之前(BEFORE) 或 之后(AFTER) 自动调用SQL命令或存储过程。通过触发器，用户可以实现 MySQL 数据库本身并不支持的一些特性。
创建触发器的语法如下：
CREATE
[DEFINER = {user | CURRENT_USER }]
TRIGER trigger_name BEFORE|AFTER INSERT|UPDATE|DELETE
ON tbl_name FOR EACH ROW trigger_stmt(程序体)
3.4.7 外键约束
之前约束创建小节例子中用过外键，这里补充其他知识点。
外键用来保证参照完整性。MySQL 数据库的 MyISAM 存储引擎本身并不支持外键，而 InnoDB 则完整支持外键约束。
外键定义如下：
[CONSTRAINT [symbol]] FOREIGN KEY
[index_name] (index_col_name, ...)
REFERENCES tbl_name (index_col_name, ...)
[ON DELETE reference_option]
[ON UPDATE reference_option]
--------------------------------------
refrence_option:
RESTRICT | CASCADE | SET NULL | NO ACTION
一般地，称被引用的表为父表，引用的表称为子表。外键定义时的 ON DELETE 和 ON UPDATE 表示在对父表进行 DELETE 或 UPDATE 操作时，对子表所做的操作。可定义的子表操作有上面 refrence_option 的四种：
-
CASCADE 表示当主表发生 DELETE 或 UPDATE 操作时，对相应子表中的数据也进行 DELETE 或 UPDATE 操作
-
SET NULL 时，对应子表的数据被更新为 NULL 值
-
RESTRICT 时，不允许主表 DELETE 或 UPDATE 操作，否则抛出错误。如果没指定 ON DELEE 或者 ON UPDATE，默认 RESTRICT
-
NO ACTION，在 MySQL 中同 RESTRICT 一样
A keyword from standard SQL. In MySQL, equivalent to RESTRICT. The MySQL Server rejects the delete or update operation for the parent table if there is a related foreign key value in the referenced table. Some database systems have deferred checks, and NO ACTION is a deferred check. In MySQL, foreign key constraints are checked immediately, so NO ACTION is the same as RESTRICT.
by https://dev.mysql.com/doc/refman/8.0/en/create-table-foreign-keys.html
3.5 视图（VIEW）
在 MySQL 中，视图是一个命令的虚拟表，它由一个 SQL 查询来定义，可以当做表使用。与持久表不同的是，视图中的数据没有实际的物理存储。
未完待续...
