Mysql-基础篇(2)-索引原理

高达 刹那F精英

目录：

• 1、索引

  • 1.1、索引图解

  • 1.2、索引类型

• 2、索引存储模型推演

  • 2.1. 二分查找

  • 2.2. 二叉查找树(BST Binary Search Tree)

  • 2.3. 平衡二叉树(AVL Tree)(左旋、右旋)

    • 2.3.1.InnoDB 逻辑存储结构

      • a、表空间 Table Space

      • b、段 Segment

      • c、簇 Extent

      • d、页 Page

      • e、行 Row

    • 2.3.2.AVL 树用于存储索引数据

  • 2.4. 多路平衡查找树(B Tree)(分裂、合并)

  • 2.5. B+树(加强版多路平衡查找树)

  • 2.6. 为什么不用红黑树?

• 3、索引使用原则

  • 3.1. 列的离散(sàn)度

  • 3.2. 联合索引最左匹配

    • 3.2.1、什么时候用到联合索引

  • 3.3、覆盖索引

  • 3.4. 索引条件下推(ICP)

• 4、索引的创建与使用

  • 4.1、索引的创建

  • 4.2、什么时候用不到索引?

---

---

---

• 1、索引

  • 1.1、索引图解

索引定义：数据库索引，是数据库管理系统(DBMS)中一个排序的数据结构，以协助快速查询、 更新数据库表中数据。

索引图解

数据是以文件的形式存放在磁盘上的，每一行数据都有它的磁盘地址。如果没有索引，要从 500 万行数据里面检索一条数据，只能依次遍历这张表的全部数据， 直到找到这条数据。
但是有了索引之后，只需要在索引里面去检索这条数据就行了，因为它是一种特殊的专门用来快速检索的数据结构，找到数据存放的磁盘地址以后，就可以拿到数据了。

• 1.2、索引类型

  • 普通(Normal)：也叫非唯一索引，是最普通的索引，没有任何的限制。
  • 唯一(Unique)：唯一索引要求键值不能重复。
    另外需要注意的是，主键索引是一种特殊的唯一索引，它还多了一个限制条件，要求键值不能为空。
    主键索引用 primay key 创建。
  • 全文(Fulltext)：针对比较大的数据，比如存放的是消息内容，有几 KB 的数 据的这种情况，如果要解决 like 查询效率低的问题，可以创建全文索引。只有文本类型的字段才可以创建全文索引，比如 char、varchar、text。

• 2、索引存储模型推演

  • 2.1. 二分查找

有序数组的等值查询和比较查询效率非常高，但是更新数据的时候会出现一个问题， 可能要挪动大量的数据(改变 index)，所以只适合存储静态的数据。
为了支持频繁的修改，比如插入数据，我们需要采用链表。链表的话，如果是单链表，它的查找效率还是不够高。
所以，有没有可以使用二分查找的链表呢?
为了解决这个问题，BST(Binary Search Tree)也就是我们所说的二叉查找树诞生 了。

• 2.2. 二叉查找树(BST Binary Search Tree)

特点：左子树所有的节点都小于父节点，右子树所有的节点都大于父节点。投影到平面以 后，就是一个有序的线性表。

二叉查找树

优点：二叉查找树既能够实现快速查找，又能够实现快速插入。
但是二叉查找树有一个问题：就是它的查找耗时是和这棵树的深度相关的，在最坏的情况下时间复杂度会退化成O(n)。
还是刚才的这一批数字，如果插入的数据刚好是有序的，2、6、11、13、17、 22。
这个时候二叉查找树变成了什么样了呢?
它会变成链表(这种树叫做“斜树”)，这种情况下不能达到加快检索速度的目的，和顺序查找效率是没有区别的。

斜树

因为左右子树深度差太大，这棵树的左子树根本没有节点——也就是它不够平衡。有没有左右子树深度相差不是那么大，更加平衡的树呢?
平衡二叉树，叫做 Balanced binary search trees，或者 AVL 树(AVL 是发明这个数据结构的人的名字)。

• 2.3. 平衡二叉树(AVL Tree)(左旋、右旋)

  • 平衡二叉树的定义：左右子树深度差绝对值不能超过 1。
    在平衡二叉树中，一个节点的大小是一个固定的单位，作为索引应该存储什么内容?
    它存储三块的内容:
    第一个是索引的键值。比如在 id 上面创建了一个索引，在用 where id =1 的条件查询的时候就会找到索引里面 id 的这个键值。
    第二个是数据的磁盘地址，因为索引的作用就是去查找数据的存放的地址。
    第三个，因为是二叉树，必须还要有左子节点和右子节点的引用，这样才能 找到下一个节点。
    
    平衡二叉树结构

【思考】如果是这样存储数据结构，会有什么问题？

在分析用 AVL 树存储索引数据之前，先来学习一下 InnoDB 的逻辑存储结构。

• 2.3.1.InnoDB 逻辑存储结构

mysql存储结构5级(空间-段-簇-页-行)

• a、表空间(Table Space)

表空间可以看做是 InnoDB 存储引擎逻辑结构的最高层，所有的数据都存放在表空间中。分为：系统表空间、独占表空间、通用表空间、 临时表空间、Undo 表空间。

• b、段(Segment)

表空间是由各个段组成的，常见的段有数据段、索引段、回滚段等，段是一个逻辑的概念。一个 ibd 文件(独立表空间文件)里面会由很多个段组成。
创建索引会创建两个段：索引段(leaf node segment)，数据段(non-leaf node segment)。
索引段管理非叶子节点的数据。数据段管理叶子节点的数据。 也就是说，一个表的段数，就是索引的个数乘以 2。

• c、簇 Extent

      一个段(Segment)又由很多的簇(也可以叫区)组成，每个区的大小是 1MB(64 个连续的页)。
每一个段至少会有一个簇，一个段所管理的空间大小是无限的，可以一直扩展下去， 但是扩展的最小单位就是簇。

• d、页 Page

      高效管理物理空间，对簇进一步细分，就得到了页。簇是由连续的页(Page) 组成的空间，一个簇中有 64 个连续的页。 (1MB/16KB=64)。这些页面在物理上和逻辑上都是连续的(I/O 实现顺序读)。
InnoDB 也有页的概念(也可以称为块)，每个页默认 16KB。 页是 InnoDB 存储引擎磁盘管理的最小单位，通过 innodb_page_size 设置。
      一个表空间最多拥有 2^32 个页，默认情况下一个页的大小为 16KB，也就是说一个表空间最多存储 64TB 的数据。
      同样，文件系统中也有页的概念。 操作系统和内存打交道，最小的单位是页 Page，文件系统的内存页通常是 4K。

文件管理系统

SHOW VARIABLES LIKE 'innodb_page_size';

eg：举例:一个页放 3 行数据。

例子

往表中插入数据时，如果一个页面已经写完，产生一个新的叶页面。如果一个簇的所有的页面都被用完，会从当前页面所在段新分配一个簇。
如果数据不是连续的，往已经写满的页中插入数据，会导致叶页面分裂：

连续空间

不连续的空间

• e、行(Row)

       InnoDB 存储引擎是面向行的(row-oriented)，也就是说数据是按行进行存放。
       Antelope[ˈæntɪləʊp]（羚羊）是 InnoDB 内置的文件格式，有两种行格式：
            REDUNDANT[rɪˈdʌndənt] Row Format
            COMPACT Row Format（5.6 默认）
       Barracuda[ˌbærəˈkjuːdə]（梭子鱼）是 InnoDB Plugin 支持的文件格式，新增了两种行格式：
            DYNAMIC Row Format（5.7 默认）
            COMPRESSED Row Format

文件格式	行格式	描述
Antelope （Innodb-base）	ROW_FORMAT=COMPACT ROW_FORMAT=REDUNDANT	Compact 和 redumdant 的区别在就是在于首部的存内容区别。 compact 存储格式首部为一个非 NULL 的变长字段长度列表。 redundant 存储格式首部是一个字段长度偏移列表（每个字段占用的字节长度及其相应的位移）。 在 Antelope 中对于变长字段，低于 768 字节的，不会进行 overflow page 存储，某些情况下会减少结果 集 IO。
Barracuda (innodb-plugin)	ROW_FORMAT=DYNAMIC ROW_FORMAT=COMPRESSED	这两者主要是功能上的区别，另外在行里的变长字段和 Antelope 的区别是只存 20 个字节， 其它的 overflow page 存储。 另外这两都需要开启 innodb_file_per_table=1。

innodb_file_format 在配置文件中指定；
row_format 则在创建数据表时指定;

 SET GLOBAL innodb_file_format=Barracuda;

在创建表的时候可以指定行格式；

CREATE TABLE tf0 (id INT PRIMARY KEY) 
ROW_FORMAT=COMPRESSED 
KEY_BLOCK_SIZE=8;

• 2.3.2.AVL 树用于存储索引数据

       当用树的结构来存储索引，访问一个节点就要跟磁盘之间发生一次 IO。 InnoDB 操作磁盘的最小的单位是一页(或者叫一个磁盘块)，大小是 16K(16384 字节)。
那么，一个树的节点就是 16K 的大小。
如果一个节点只存一个键值+数据+引用，例如整形的字段，可能只用了十几个或者几十个字节，它远远达不到 16K 的容量，所以访问一个树节点，进行一次 IO 的时候， 浪费了大量的空间。
所以如果每个节点存储的数据太少，从索引中找到我们需要的数据，就要访问更多的节点，意味着跟磁盘交互次数就会过多。
如果是机械硬盘时代，每次从磁盘读取数据需要 10ms 左右的寻址时间，交互次数越多，消耗的时间就越多。

AVL索引结构

       比如上面这张图，一张表里面有 6 条数据，当我们查询 id=37 的时候，要查询两个子节点，就需要跟磁盘交互 3 次，如果有几百万的数据呢?这个时间更加难以估计。
针对上面的解决方案是什么呢?
第一个就是让每个节点存储更多的数据。
第二个，节点上的关键字的数量越多，指针数也越多，也就是意味着可以有更多的分叉(把它叫做“路数”)。
因为分叉数越多，树的深度就会减少(根节点是 0)。 这样的树是不是从原来的高瘦高瘦的样子，变成了矮胖矮胖的样子?
这个时候，我们的树就不再是二叉了，而是多叉 or 多路。

• 2.4. 多路平衡查找树(B Tree)(分裂、合并)

       Balanced Tree这个就是我们的多路平衡查找树，叫做 B Tree(B 代表平衡)。
跟 AVL 树一样，B 树在枝节点和叶子节点存储键值、数据地址、节点引用。 它有一个特点:分叉数(路数)永远比关键字数多 1。比如我们画的这棵树，每个节
点存储两个关键字，那么就会有三个指针指向三个子节点。

多路平衡二叉树

B Tree 的查找规则是什么样的呢? 比如我们要在这张表里面查找 15。
因为 15 小于 17，走左边。
因为 15 大于 12，走右边。
在磁盘块 7 里面就找到了 15，只用了 3 次 IO。

如果删除节点，会有相反的合并的操作。 注意这里是分裂和合并，跟 AVL 树的左旋和右旋是不一样的。 我们继续插入 4 和 5，B Tree 又会出现分裂和合并的操作。

image.png

从这个里面我们也能看到，在更新索引的时候会有大量的索引的结构的调整，所以 解释了为什么我们不要在频繁更新的列上建索引，或者为什么不要更新主键。
节点的分裂和合并，其实就是 InnoDB 页的分裂和合并。

• 2.5. B+树(加强版多路平衡查找树)

B Tree 的效率已经很高了，为什么 MySQL 还要对 B Tree 进行改良，最终使用了 B+Tree 呢?
总体上来说，这个 B 树的改良版本解决的问题比 B Tree 更全面。 我们来看一下 InnoDB 里面的 B+树的存储结构：

B+树

MySQL 中的 B+Tree 有几个特点:

• 1、它的关键字的数量是跟路数相等的;
• 2、B+Tree 的根节点和枝节点中都不会存储数据，只有叶子节点才存储数据。搜索
  到关键字不会直接返回，会到最后一层的叶子节点。比如我们搜索 id=28，虽然在第一 层直接命中了，但是全部的数据在叶子节点上面，所以我还要继续往下搜索，一直到叶 子节点。
  举个例子:假设一条记录是 1K，一个叶子节点(一页)可以存储 16 条记录。非叶 子节点可以存储多少个指针?

假设索引字段是 bigint 类型，长度为 8 字节。指针大小在 InnoDB 源码中设置为 6 字节，这样一共 14 字节。非叶子节点(一页)可以存储 16384/14=1170 个这样的 单元(键值+指针)，代表有 1170 个指针。

树深度为 2 的时候，有 1170^2 个叶子节点，可以存储的数据为 1170117016=21902400。
在查找数据时一次页的查找代表一次 IO，也就是说，一张 2000 万左右的表，查询 数据最多需要访问 3 次磁盘。

所以在 InnoDB 中 B+ 树深度一般为 1-3 层，它就能满足千万级的数据存储。

• 3、B+Tree 的每个叶子节点增加了一个指向相邻叶子节点的指针，它的最后一个数 据会指向下一个叶子节点的第一个数据，形成了一个有序链表的结构。
• 4、它是根据左闭右开的区间 [ )来检索数据。我们来看一下 B+Tree 的数据搜寻过程:
  • 1)、比如我们要查找 28，在根节点就找到了键值，但是因为它不是页子节点，所以 会继续往下搜寻，28 是[28,66)的左闭右开的区间的临界值，所以会走中间的子节点，然 后继续搜索，它又是[28,34)的左闭右开的区间的临界值，所以会走左边的子节点，最后 在叶子节点上找到了需要的数据。
  • 2)、第二个，如果是范围查询，比如要查询从 22 到 60 的数据，当找到 22 之后，只 需要顺着节点和指针顺序遍历就可以一次性访问到所有的数据节点，这样就极大地提高了区间查询效率(不需要返回上层父节点重复遍历查找)。

总结一下，InnoDB 中的 B+Tree 的特点:
       1)、它是 B Tree 的变种，B Tree 能解决的问题，它都能解决。B Tree 解决的两大问题 是什么?(每个节点存储更多关键字;路数更多)
       2)、扫库、扫表能力更强(如果我们要对表进行全表扫描，只需要遍历叶子节点就可以 了，不需要遍历整棵 B+Tree 拿到所有的数据)
       3)、B+Tree 的磁盘读写能力相对于 B Tree 来说更强(根节点和枝节点不保存数据区， 所以一个节点可以保存更多的关键字，一次磁盘加载的关键字更多)
       4)、排序能力更强(因为叶子节点上有下一个数据区的指针，数据形成了链表) 5)效率更加稳定(B+Tree 永远是在叶子节点拿到数据，所以 IO 次数是稳定的)

【思考：为什么不用红黑树?】
红黑树也是 BST 树，但是不是严格平衡的。
必须满足 5 个约束：
1、节点分为红色或者黑色。
2、根节点必须是黑色的。
3、叶子节点都是黑色的 NULL 节点。
4、红色节点的两个子节点都是黑色（不允许两个相邻的红色节点）。
5、从任意节点出发，到其每个叶子节点的路径中包含相同数量的黑色节点。 插入：60、56、68、45、64、58、72、43、49

插入红黑数

基于以上规则，可以推导出：
从根节点到叶子节点的最长路径（红黑相间的路径）不大于最短路径（全部是黑色 节点）的 2 倍。 为什么不用红黑树？
1、只有两路；
2、不够平衡。 红黑树一般只放在内存里面用。例如 Java 的 TreeMap。

3、索引使用原则

      容易有这样一个误区，在经常使用的查询条件上都建立索引，索引越多越好， 那到底是不是这样呢？

• 3.1、列的离散(sàn)度

       列的离散度的公式：count(distinct(column_name)) : count(1) ，列的全部不同值和所有数据行的比例。
数据行数相同的情况下，分子越大，列的离散度就越高。

id	name	gender	iphone
1	kobe	1	18612548765
2	james	1	18817064436
3	Jenner	0	18755326679
4	me	1	188-------

简单来说，如果列的重复值越多，离散度就越低，重复值越少，离散度就越高。
了解了离散度的概念之后，思考一个问题，在 name 上面建立索引和 在 gender 上面建立索引有什么区别?
当我们用在 gender 上建立的索引去检索数据的时候，由于重复值太多，需要扫描的 行数就更多。
例如，我们现在在 gender 列上面创建一个索引，然后看一下执行计划。

ALTER TABLE user_innodb ADD INDEX idx_user_gender (gender); 
EXPLAIN SELECT * FROM `user_innodb` WHERE gender = 0;

index-gender explain结果

show indexes from user_innodb;

而 name 的离散度更高，比如“Jenner”的这名字，只需要扫描一行。

ALTER TABLE user_innodb ADD INDEX idx_user_name (name); 
EXPLAIN SELECT * FROM `user_innodb` WHERE name = '青山';

index-name explain 结果

查看表上的索引，Cardinality [kɑ:dɪ'nælɪtɪ] 代表基数，代表预估的不重复的值的数量。
索引的基数与表总行数越接近，列的离散度就越高。

结论：如果在 B+Tree 里面的重复值太多，MySQL 的优化器发现走索引跟使用全表扫描差，不了多少的时候，就算建了索引，也不一定会走索引。

重复值太多BadCase

这个给我们的启发是什么？建立索引，要使用离散度（选择度）更高的字段。

3.2、联合索引最左匹配

       前面都是针对单列创建的索引，对于多条件查询的时候，也会建立联合索引。
单列索引可以看成是特殊的联合索引。 比如我们在 user 表上面，给 name 和 phone 建立了一个联合索引。

ALTER TABLE user_innodb add INDEX comidx_name_phone (name,phone);

name,phone 联合索引B+Tree数据结构

联合索引在 B+Tree 中是复合的数据结构，它是按照从左到右的顺序来建立搜索树（name 在左边，phone 在右边）。
从这张图可以看出来，name 是有序的，phone 是无序的。
当 name 相等的时候， phone 才是有序的。 这个时候我们使用 where name= 'Janner' and phone = '136xx '去查询数据的时候， B+Tree 会优先比较 name 来确定下一步应该搜索的方向，往左还是往右。如果 name 相同的时候再比较 phone。但是如果查询条件没有 name，就不知道第一步应该查哪个节点，因为建立搜索树的时候 name 是第一个比较因子，所以用不到索引。

【思考：什么时候用到联合索引？】

• eg：我们在建立联合索引的时候，一定要把最常用的列放在最左边。 比如下面的三条语句，能用到联合索引吗？
  • 1）使用两个字段，可以用到联合索引：

EXPLAIN SELECT * FROM user_innodb WHERE name= 'Janner' AND phone = '15204661800';

image.png

• 2）使用左边的 name 字段，可以用到联合索引：

EXPLAIN SELECT * FROM user_innodb WHERE name= 'Janner';

image.png

• 3）使用右边的 phone 字段，无法使用索引，全表扫描：

EXPLAIN SELECT * FROM user_innodb WHERE phone = '15204661800';

image.png

3.3、覆盖索引

       回表： 非主键索引，先通过索引找到主键索引的键值，再通过主键值查出索引里面没有的数据，它比基于主键索引的查询多扫描了一棵索引树，这个过程就叫回表。

回表图解

       在辅助索引里面，不管是单列索引还是联合索引，如果 select 的数据列只用从索引 中就能够取得，不必从数据区中读取，这时候使用的索引就叫做覆盖索引，这样就避免了回表。
这三个查询语句都用到了覆盖索引：

-- 创建联合索引 
ALTER TABLE user_innodb DROP INDEX comixd_name_phone; 
ALTER TABLE user_innodb add INDEX `comixd_name_phone` (`name`,`phone`);

EXPLAIN SELECT name,phone FROM user_innodb WHERE name= 'Janner' AND phone = ' 13666666666'; 
EXPLAIN SELECT name FROM user_innodb WHERE name= 'Janner' AND phone = ' 13666666666'; 
EXPLAIN SELECT phone FROM user_innodb WHERE name= 'Janner' AND phone = ' 13666666666';

Extra 里面值为“Using index”代表使用了覆盖索引。

image.png

select * ，用不到覆盖索引。
结论：很明显，因为覆盖索引减少了 IO 次数，减少了数据的访问量，可以大大地提升查询效率。

3.4、索引下推（ICP）

       有这么一张表，在 last_name 和 first_name 上面创建联合索引。

drop table employees; 
CREATE TABLE `employees` ( 
`emp_no` int(11) NOT NULL, 
`birth_date` date NULL, 
`first_name` varchar(14) NOT NULL,
`last_name` varchar(16) NOT NULL, 
`gender` enum('M','F') NOT NULL, 
`hire_date` date NULL, 
PRIMARY KEY (`emp_no`) 
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

-- 创建联合索引
alter table employees add index idx_lastname_firstname(last_name,first_name); 

INSERT INTO `employees` (`emp_no`, `birth_date`, `first_name`, `last_name`, `gender`, `hire_date`) VALUES (1, NULL, '698', 'liu', 'F', NULL); 
INSERT INTO `employees` (`emp_no`, `birth_date`, `first_name`, `last_name`, `gender`, `hire_date`) VALUES (2, NULL, 'd99', 'zheng', 'F', NULL);
INSERT INTO `employees` (`emp_no`, `birth_date`, `first_name`, `last_name`, `gender`, `hire_date`) VALUES (3, NULL, 'e08', 'huang', 'F', NULL); 
INSERT INTO `employees` (`emp_no`, `birth_date`, `first_name`, `last_name`, `gender`, `hire_date`) VALUES (4, NULL, '59d', 'lu', 'F', NULL); 
INSERT INTO `employees` (`emp_no`, `birth_date`, `first_name`, `last_name`, `gender`, `hire_date`) VALUES (5, NULL, '0dc', 'yu', 'F', NULL);
INSERT INTO `employees` (`emp_no`, `birth_date`, `first_name`, `last_name`, `gender`, `hire_date`) VALUES (6, NULL, '989', 'wang', 'F', NULL); 
INSERT INTO `employees` (`emp_no`, `birth_date`, `first_name`, `last_name`, `gender`, `hire_date`) VALUES (7, NULL, 'e38', 'wang', 'F', NULL); 
INSERT INTO `employees` (`emp_no`, `birth_date`, `first_name`, `last_name`, `gender`, `hire_date`) VALUES (8, NULL, '0zi', 'wang', 'F', NULL); 
INSERT INTO `employees` (`emp_no`, `birth_date`, `first_name`, `last_name`, `gender`, `hire_date`) VALUES (9, NULL, 'dc9', 'xie', 'F', NULL);
INSERT INTO `employees` (`emp_no`, `birth_date`, `first_name`, `last_name`, `gender`, `hire_date`) VALUES (10, NULL, '5ba', 'zhou', 'F', NULL);

关闭 ICP：

set optimizer_switch='index_condition_pushdown=off';

现在我们要查询所有姓 wang，并且名字最后一个字是 zi 的员工，比如王胖子，王瘦子。查询的 SQL：

select * from employees where last_name='wang' and first_name LIKE '%zi' ;

这条 SQL 有两种执行方式：
       1、根据联合索引查出所有姓 wang 的二级索引数据，然后回表，到主键索引上查询全部符合条件的数据（3 条数据）。然后返回给 Server 层，在 Server 层过滤出名字以 zi 结尾的员工。
       2、根据联合索引查出所有姓 wang 的二级索引数据（3 个索引），然后从二级索引中筛选出 first_name 以 zi 结尾的索引（1 个索引），然后再回表，到主键索引上查询全 部符合条件的数据（1 条数据），返回给 Server 层。

image.png

很明显，第二种方式到主键索引上查询的数据更少。
注意，索引的比较是在存储引擎进行的，数据记录的比较，是在 Server 层进行的。
而当 first_name 的条件不能用于索引过滤时，Server 层不会把 first_name 的条件传递给存储引擎，所以读取了两条没有必要的记录。
这时候，如果满足 last_name='wang'的记录有 100000 条，就会有 99999 条没有 必要读取的记录。
执行以下 SQL，Using where：

explain select * from employees where last_name='wang' and first_name LIKE '%zi' ;

image.png

       Using Where 代表从存储引擎取回的数据不全部满足条件，需要在 Server 层过滤。
先用 last_name 条件进行索引范围扫描，读取数据表记录，此时是3条，然后进行比较，检查是否符合 first_name LIKE '%zi' 的条件。此时 3 条中只有 1 条符合条件。

开启 ICP：

set optimizer_switch='index_condition_pushdown=on';

此时的执行计划，Using index condition：

image.png

       把 first_name LIKE '%zi'下推给存储引擎后，只会从数据表读取所需的 1 条记录。
       索引条件下推（Index Condition Pushdown），5.6 以后完善的功能。只适用于二级索引。ICP 的目标是减少访问表的完整行的读数量从而减少 I/O 操作。

---

---

---

5、面试常见问题

• 5.1、为什么不建议使用ForeignKey 外键？

  • 1、MySQL、PostgreSQL 等关系型数据库很难水平扩容，但是无状态的服务往往都可以很容易地扩容。由于外键等特性需要数据库执行额外的工作，这些操作会占用数据库的计算资源，所以可以将大部分的需求都迁移到无状态的服务中完成以降低数据库的工作负载。【因为应用水平扩展代价更小】
  • 2、不同类型的外键会给数据库带来不同的额外开销。
    • a、使用 RESTRICT 会在更新或者删除记录时对外键对应的记录是否存在进行一致性检查；
    • b、使用 CASCADE 会在更新或者删除记录时触发级联更新或者删除操作。

---

---

---

参考资料：

《数据库查询优化器的艺术-原理解析与SQL性能优化》
《MySQL高性能书籍第3版（中文）》
《MySQL技术内幕-InnoDB存储引擎第2版》