auto commit
This commit is contained in:
CyC2018
parent
0889a9a452
commit
36c369f71b
|
|
@ -14,10 +14,6 @@
|
|||
|
||||
目录按《剑指 Offer 第二版》编排，在牛客网的在线编程中出现的题目都已经 AC。
|
||||
|
||||
> [2016 校招真题题解](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/2016%20校招真题题解.md)
|
||||
|
||||
未完成
|
||||
|
||||
# 网络
|
||||
|
||||
> [计算机网络](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/计算机网络.md)
|
||||
|
|
|
|||
418
notes/MySQL.md
418
notes/MySQL.md
|
|
@ -1,227 +1,249 @@
|
|||
<!-- GFM-TOC -->
|
||||
* [存储引擎](#存储引擎)
|
||||
* [事务四大特性](#事务四大特性)
|
||||
* [1. 原子性](#1-原子性)
|
||||
* [2. 一致性](#2-一致性)
|
||||
* [3. 隔离性](#3-隔离性)
|
||||
* [4. 持久性](#4-持久性)
|
||||
* [存储引擎](#存储引擎)
|
||||
* [1. InnoDB](#1-innodb)
|
||||
* [2. MyISAM](#2-myisam)
|
||||
* [3. InnoDB 与 MyISAM 的比较](#3-innodb-与-myisam-的比较)
|
||||
* [数据类型](#数据类型)
|
||||
* [1. 整型](#1-整型)
|
||||
* [2. 浮点数](#2-浮点数)
|
||||
* [3. 字符串](#3-字符串)
|
||||
* [4. 时间和日期](#4-时间和日期)
|
||||
* [索引](#索引)
|
||||
* [1. 索引分类](#1-索引分类)
|
||||
* [1.1 B-Tree 索引](#11-b-tree-索引)
|
||||
* [1.2 哈希索引](#12-哈希索引)
|
||||
* [1.3. 空间索引数据（R-Tree）](#13-空间索引数据（r-tree）)
|
||||
* [1.4 全文索引](#14-全文索引)
|
||||
* [2. 索引的优点](#2-索引的优点)
|
||||
* [3. 索引优化](#3-索引优化)
|
||||
* [3.1 独立的列](#31-独立的列)
|
||||
* [3.2 前缀索引](#32-前缀索引)
|
||||
* [3.3 多列索引](#33-多列索引)
|
||||
* [3.4 索引列的顺序](#34-索引列的顺序)
|
||||
* [3.5 聚簇索引](#35-聚簇索引)
|
||||
* [3.6 覆盖索引](#36-覆盖索引)
|
||||
* [4. B-Tree 和 B+Tree 原理](#4-b-tree-和-b+tree-原理)
|
||||
* [3. InnoDB 与 MyISAM 的比较](#3-innodb-与-myisam-的比较)
|
||||
* [数据类型](#数据类型)
|
||||
* [1. 整型](#1-整型)
|
||||
* [2. 浮点数](#2-浮点数)
|
||||
* [3. 字符串](#3-字符串)
|
||||
* [4. 时间和日期](#4-时间和日期)
|
||||
* [索引](#索引)
|
||||
* [1. 索引分类](#1-索引分类)
|
||||
* [1.1 B-Tree 索引](#11-b-tree-索引)
|
||||
* [1.2 哈希索引](#12-哈希索引)
|
||||
* [1.3. 空间索引数据（R-Tree）](#13-空间索引数据（r-tree）)
|
||||
* [1.4 全文索引](#14-全文索引)
|
||||
* [2. 索引的优点](#2-索引的优点)
|
||||
* [3. 索引优化](#3-索引优化)
|
||||
* [3.1 独立的列](#31-独立的列)
|
||||
* [3.2 前缀索引](#32-前缀索引)
|
||||
* [3.3 多列索引](#33-多列索引)
|
||||
* [3.4 索引列的顺序](#34-索引列的顺序)
|
||||
* [3.5 聚簇索引](#35-聚簇索引)
|
||||
* [3.6 覆盖索引](#36-覆盖索引)
|
||||
* [4. B-Tree 和 B+Tree 原理](#4-b-tree-和-b+tree-原理)
|
||||
* [4. 1 B-Tree](#4-1-b-tree)
|
||||
* [4.2 B+Tree](#42-b+tree)
|
||||
* [4.3 带有顺序访问指针的 B+Tree](#43-带有顺序访问指针的-b+tree)
|
||||
* [4.4 为什么使用 B-Tree 和 B+Tree](#44-为什么使用-b-tree-和-b+tree)
|
||||
* [查询性能优化](#查询性能优化)
|
||||
* [4.3 带有顺序访问指针的 B+Tree](#43-带有顺序访问指针的-b+tree)
|
||||
* [4.4 为什么使用 B-Tree 和 B+Tree](#44-为什么使用-b-tree-和-b+tree)
|
||||
* [查询性能优化](#查询性能优化)
|
||||
* [1. Explain](#1-explain)
|
||||
* [2. 减少返回的列](#2-减少返回的列)
|
||||
* [3. 减少返回的行](#3-减少返回的行)
|
||||
* [4. 拆分大的 DELETE 或 INSERT 语句](#4-拆分大的-delete-或-insert-语句)
|
||||
* [分库与分表](#分库与分表)
|
||||
* [故障转移和故障恢复](#故障转移和故障恢复)
|
||||
* [1. 故障转移](#1-故障转移)
|
||||
* [2. 故障恢复](#2-故障恢复)
|
||||
* [参考资料](#参考资料)
|
||||
* [2. 减少返回的列](#2-减少返回的列)
|
||||
* [3. 减少返回的行](#3-减少返回的行)
|
||||
* [4. 拆分大的 DELETE 或 INSERT 语句](#4-拆分大的-delete-或-insert-语句)
|
||||
* [分库与分表](#分库与分表)
|
||||
* [故障转移和故障恢复](#故障转移和故障恢复)
|
||||
* [1. 故障转移](#1-故障转移)
|
||||
* [2. 故障恢复](#2-故障恢复)
|
||||
* [参考资料](#参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
# 事务四大特性
|
||||
|
||||
# 存储引擎
|
||||
## 1. 原子性
|
||||
|
||||
要么都执行，要么都不执行。
|
||||
|
||||
## 2. 一致性
|
||||
|
||||
事务执行前后都保持一致性状态。
|
||||
|
||||
## 3. 隔离性
|
||||
|
||||
多个事务单独执行，互不影响。
|
||||
|
||||
## 4. 持久性
|
||||
|
||||
即使系统发生故障，事务执行的结果也不能丢失。
|
||||
|
||||
# 存储引擎
|
||||
|
||||
## 1. InnoDB
|
||||
|
||||
InnoDB 是 MySQL 的默认事务型引擎，只有在需要 InnoDB 不支持的特性时，才考虑使用其它存储引擎。
|
||||
InnoDB 是 MySQL 的默认事务型引擎，只有在需要 InnoDB 不支持的特性时，才考虑使用其它存储引擎。
|
||||
|
||||
采用 MVCC 来支持高并发，并且实现了四个标准的隔离级别，默认级别是可重复读。
|
||||
采用 MVCC 来支持高并发，并且实现了四个标准的隔离级别，默认级别是可重复读。
|
||||
|
||||
表是基于聚簇索引建立的，它对主键的查询性能有很高的提升。
|
||||
表是基于聚簇索引建立的，它对主键的查询性能有很高的提升。
|
||||
|
||||
内部做了很多优化，包括从磁盘读取数据时采用的可预测性读，能够自动在内存中创建 hash 索引以加速读操作的自适应哈希索引，以及能够加速插入操作的插入缓冲区等。
|
||||
内部做了很多优化，包括从磁盘读取数据时采用的可预测性读，能够自动在内存中创建 hash 索引以加速读操作的自适应哈希索引，以及能够加速插入操作的插入缓冲区等。
|
||||
|
||||
通过一些机制和工具支持真正的热备份。
|
||||
通过一些机制和工具支持真正的热备份。
|
||||
|
||||
## 2. MyISAM
|
||||
|
||||
MyISAM 提供了大量的特性，包括全文索引、压缩、空间函数（GIS）等。但 MyISAM 不支持事务和行级锁，而且奔溃后无法安全恢复。
|
||||
MyISAM 提供了大量的特性，包括全文索引、压缩、空间函数（GIS）等。但 MyISAM 不支持事务和行级锁，而且奔溃后无法安全恢复。
|
||||
|
||||
只能对整张表加锁，而不是针对行。
|
||||
只能对整张表加锁，而不是针对行。
|
||||
|
||||
可以手工或者自动执行检查和修复操作，但是和事务恢复以及奔溃恢复不同，可能导致一些数据丢失，而且修复操作是非常慢的。
|
||||
可以手工或者自动执行检查和修复操作，但是和事务恢复以及奔溃恢复不同，可能导致一些数据丢失，而且修复操作是非常慢的。
|
||||
|
||||
可以包含动态或者静态的行。
|
||||
可以包含动态或者静态的行。
|
||||
|
||||
如果指定了 DELAY_KEY_WRITE 选项，在每次修改执行完成时，不会立即将修改的索引数据写入磁盘，而是会写到内存中的键缓冲区，只有在清理键缓冲区或者关闭表的时候才会将对应的索引块写入磁盘。这种方式可以极大的提升写入性能，但是在数据库或者主机奔溃时会造成索引损坏，需要执行修复操作。
|
||||
如果指定了 DELAY_KEY_WRITE 选项，在每次修改执行完成时，不会立即将修改的索引数据写入磁盘，而是会写到内存中的键缓冲区，只有在清理键缓冲区或者关闭表的时候才会将对应的索引块写入磁盘。这种方式可以极大的提升写入性能，但是在数据库或者主机奔溃时会造成索引损坏，需要执行修复操作。
|
||||
|
||||
如果表在创建并导入数据以后，不会再进行修改操作，那么这样的表适合采用 MyISAM 压缩表。
|
||||
如果表在创建并导入数据以后，不会再进行修改操作，那么这样的表适合采用 MyISAM 压缩表。
|
||||
|
||||
对于只读数据，或者表比较小、可以容忍修复操作，则依然可以继续使用 MyISAM。
|
||||
对于只读数据，或者表比较小、可以容忍修复操作，则依然可以继续使用 MyISAM。
|
||||
|
||||
MyISAM 设计简单，数据以紧密格式存储，所以在某些场景下性能很好。
|
||||
MyISAM 设计简单，数据以紧密格式存储，所以在某些场景下性能很好。
|
||||
|
||||
## 3. InnoDB 与 MyISAM 的比较
|
||||
## 3. InnoDB 与 MyISAM 的比较
|
||||
|
||||
**事务**
|
||||
**事务**
|
||||
|
||||
InnoDB 是事务型的。
|
||||
InnoDB 是事务型的。
|
||||
|
||||
**备份**
|
||||
**备份**
|
||||
|
||||
InnoDB 支持在线热备份。
|
||||
InnoDB 支持在线热备份。
|
||||
|
||||
**奔溃恢复**
|
||||
**奔溃恢复**
|
||||
|
||||
MyISAM 奔溃后发生损坏的概率比 InnoDB 高很多，而且恢复的速度也更慢。
|
||||
MyISAM 奔溃后发生损坏的概率比 InnoDB 高很多，而且恢复的速度也更慢。
|
||||
|
||||
**并发**
|
||||
**并发**
|
||||
|
||||
MyISAM 只支持表级锁，而 InnoDB 还支持行级锁。
|
||||
MyISAM 只支持表级锁，而 InnoDB 还支持行级锁。
|
||||
|
||||
**其它特性**
|
||||
**其它特性**
|
||||
|
||||
MyISAM 支持全文索引，地理空间索引；
|
||||
MyISAM 支持全文索引，地理空间索引；
|
||||
|
||||
# 数据类型
|
||||
# 数据类型
|
||||
|
||||
## 1. 整型
|
||||
## 1. 整型
|
||||
|
||||
TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT 分别使用 8, 16, 24, 64 位存储空间，一般情况下越小的列越好。
|
||||
TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT 分别使用 8, 16, 24, 64 位存储空间，一般情况下越小的列越好。
|
||||
|
||||
INT(11) 中的数字只是规定了交互工具显示字符的个数，对于存储和计算来说是没有意义的。
|
||||
INT(11) 中的数字只是规定了交互工具显示字符的个数，对于存储和计算来说是没有意义的。
|
||||
|
||||
## 2. 浮点数
|
||||
## 2. 浮点数
|
||||
|
||||
FLOAT 和 DOUBLE 为浮点类型，DECIMAL 为高精度小数类型。CPU 原生支持浮点运算，但是不支持 DECIMAl 类型的计算，因此 DECIMAL 的计算比浮点类型需要更高的代价。
|
||||
FLOAT 和 DOUBLE 为浮点类型，DECIMAL 为高精度小数类型。CPU 原生支持浮点运算，但是不支持 DECIMAl 类型的计算，因此 DECIMAL 的计算比浮点类型需要更高的代价。
|
||||
|
||||
FLOAT、DOUBLE 和 DECIMAL 都可以指定列宽，例如 DECIMAL(18, 9) 表示总共 18 位，取 9 位存储小数部分，剩下 9 位存储整数部分。
|
||||
FLOAT、DOUBLE 和 DECIMAL 都可以指定列宽，例如 DECIMAL(18, 9) 表示总共 18 位，取 9 位存储小数部分，剩下 9 位存储整数部分。
|
||||
|
||||
## 3. 字符串
|
||||
## 3. 字符串
|
||||
|
||||
主要有 CHAR 和 VARCHAR 两种类型，一种是定长的，一种是变长的。
|
||||
主要有 CHAR 和 VARCHAR 两种类型，一种是定长的，一种是变长的。
|
||||
|
||||
VARCHAR 这种变长类型能够节省空间，因为只需要存储必要的内容。但是在执行 UPDATE 时可能会使行变得比原来长，当超出一个页所能容纳的大小时，就要执行额外的操作，MyISAM 会将行拆成不同的片段存储，而 InnoDB 则需要分裂页来使行放进页内。
|
||||
VARCHAR 这种变长类型能够节省空间，因为只需要存储必要的内容。但是在执行 UPDATE 时可能会使行变得比原来长，当超出一个页所能容纳的大小时，就要执行额外的操作，MyISAM 会将行拆成不同的片段存储，而 InnoDB 则需要分裂页来使行放进页内。
|
||||
|
||||
VARCHAR 会保留字符串末尾的空格，而 CHAR 会删除。
|
||||
VARCHAR 会保留字符串末尾的空格，而 CHAR 会删除。
|
||||
|
||||
## 4. 时间和日期
|
||||
## 4. 时间和日期
|
||||
|
||||
MySQL 提供了两种相似的日期时间类型：DATATIME 和 TIMESTAMP。
|
||||
MySQL 提供了两种相似的日期时间类型：DATATIME 和 TIMESTAMP。
|
||||
|
||||
**DATATIME**
|
||||
|
||||
能够保存从 1001 年到 9999 年的日期和时间，精度为秒，使用 8 字节的存储空间。
|
||||
能够保存从 1001 年到 9999 年的日期和时间，精度为秒，使用 8 字节的存储空间。
|
||||
|
||||
它与时区无关。
|
||||
它与时区无关。
|
||||
|
||||
默认情况下，MySQL 以一种可排序的、无歧义的格式显示 DATATIME 值，例如“2008-01016 22:37:08”，这是 ANSI 标准定义的日期和时间表示方法。
|
||||
默认情况下，MySQL 以一种可排序的、无歧义的格式显示 DATATIME 值，例如“2008-01016 22:37:08”，这是 ANSI 标准定义的日期和时间表示方法。
|
||||
|
||||
**TIMESTAMP**
|
||||
|
||||
和 UNIX 时间戳相同，保存从 1970 年 1 月 1 日午夜（格林威治时间）以来的秒数，使用 4 个字节，只能表示从 1970 年 到 2038 年。
|
||||
和 UNIX 时间戳相同，保存从 1970 年 1 月 1 日午夜（格林威治时间）以来的秒数，使用 4 个字节，只能表示从 1970 年 到 2038 年。
|
||||
|
||||
它和时区有关。
|
||||
它和时区有关。
|
||||
|
||||
MySQL 提供了 FROM_UNIXTIME() 函数把 Unxi 时间戳转换为日期，并提供了 UNIX_TIMESTAMP() 函数把日期转换为 Unix 时间戳。
|
||||
MySQL 提供了 FROM_UNIXTIME() 函数把 Unxi 时间戳转换为日期，并提供了 UNIX_TIMESTAMP() 函数把日期转换为 Unix 时间戳。
|
||||
|
||||
默认情况下，如果插入时没有指定 TIMESTAMP 列的值，会将这个值设置为当前时间。
|
||||
默认情况下，如果插入时没有指定 TIMESTAMP 列的值，会将这个值设置为当前时间。
|
||||
|
||||
应该尽量使用 TIMESTAMP，因为它比 DATETIME 空间效率更高。
|
||||
应该尽量使用 TIMESTAMP，因为它比 DATETIME 空间效率更高。
|
||||
|
||||
# 索引
|
||||
# 索引
|
||||
|
||||
索引是在存储引擎层实现的，而不是在服务器层实现的，所以不同存储引擎具有不同的索引类型和实现。
|
||||
索引是在存储引擎层实现的，而不是在服务器层实现的，所以不同存储引擎具有不同的索引类型和实现。
|
||||
|
||||
索引能够轻易将查询性能提升几个数量级。
|
||||
索引能够轻易将查询性能提升几个数量级。
|
||||
|
||||
对于非常小的表、大部分情况下简单的全表扫描比建立索引更高效。对于中到大型的表，索引就非常有效。但是对于特大型的表，建立和使用索引的代价将会随之增长。这种情况下，需要用到一种技术可以直接区分出需要查询的一组数据，而不是一条记录一条记录地匹配，例如可以使用分区技术。
|
||||
对于非常小的表、大部分情况下简单的全表扫描比建立索引更高效。对于中到大型的表，索引就非常有效。但是对于特大型的表，建立和使用索引的代价将会随之增长。这种情况下，需要用到一种技术可以直接区分出需要查询的一组数据，而不是一条记录一条记录地匹配，例如可以使用分区技术。
|
||||
|
||||
## 1. 索引分类
|
||||
## 1. 索引分类
|
||||
|
||||
### 1.1 B-Tree 索引
|
||||
### 1.1 B-Tree 索引
|
||||
|
||||
B-Tree 索引是大多数 MySQL 存储引擎的默认索引类型。
|
||||
B-Tree 索引是大多数 MySQL 存储引擎的默认索引类型。
|
||||
|
||||
因为不再需要进行全表扫描，只需要对树进行搜索即可，因此查找速度快很多。
|
||||
因为不再需要进行全表扫描，只需要对树进行搜索即可，因此查找速度快很多。
|
||||
|
||||
可以指定多个列作为索引列，多个索引列共同组成键。B-Tree 索引适用于全键值、键值范围和键前缀查找，其中键前缀查找只适用于最左前缀查找。
|
||||
可以指定多个列作为索引列，多个索引列共同组成键。B-Tree 索引适用于全键值、键值范围和键前缀查找，其中键前缀查找只适用于最左前缀查找。
|
||||
|
||||
除了用于查找，还可以用于排序和分组。
|
||||
除了用于查找，还可以用于排序和分组。
|
||||
|
||||
如果不是按照索引列的顺序进行查找，则无法使用索引。
|
||||
如果不是按照索引列的顺序进行查找，则无法使用索引。
|
||||
|
||||
### 1.2 哈希索引
|
||||
### 1.2 哈希索引
|
||||
|
||||
基于哈希表实现，优点是查找非常快。
|
||||
基于哈希表实现，优点是查找非常快。
|
||||
|
||||
在 MySQL 中只有 Memory 引擎显式支持哈希索引。
|
||||
在 MySQL 中只有 Memory 引擎显式支持哈希索引。
|
||||
|
||||
InnoDB 引擎有一个特殊的功能叫“自适应哈希索引”，当某个索引值被使用的非常频繁时，会在 B-Tree 索引之上再创建一个哈希索引，这样就让 B-Tree 索引具有哈希索引的一些优点，比如快速的哈希查找。
|
||||
InnoDB 引擎有一个特殊的功能叫“自适应哈希索引”，当某个索引值被使用的非常频繁时，会在 B-Tree 索引之上再创建一个哈希索引，这样就让 B-Tree 索引具有哈希索引的一些优点，比如快速的哈希查找。
|
||||
|
||||
限制：哈希索引只包含哈希值和行指针，而不存储字段值，所以不能使用索引中的值来避免读取行。不过，访问内存中的行的速度很快，所以大部分情况下这一点对性能影响并不明显；无法用于分组与排序；只支持精确查找，无法用于部分查找和范围查找；如果哈希冲突很多，查找速度会变得很慢。
|
||||
限制：哈希索引只包含哈希值和行指针，而不存储字段值，所以不能使用索引中的值来避免读取行。不过，访问内存中的行的速度很快，所以大部分情况下这一点对性能影响并不明显；无法用于分组与排序；只支持精确查找，无法用于部分查找和范围查找；如果哈希冲突很多，查找速度会变得很慢。
|
||||
|
||||
### 1.3. 空间索引数据（R-Tree）
|
||||
### 1.3. 空间索引数据（R-Tree）
|
||||
|
||||
MyISAM 存储引擎支持空间索引，可以用于地理数据存储。
|
||||
MyISAM 存储引擎支持空间索引，可以用于地理数据存储。
|
||||
|
||||
空间索引会从所有维度来索引数据，可以有效地使用任意维度来进行组合查询。
|
||||
空间索引会从所有维度来索引数据，可以有效地使用任意维度来进行组合查询。
|
||||
|
||||
### 1.4 全文索引
|
||||
### 1.4 全文索引
|
||||
|
||||
MyISAM 存储引擎支持全文索引，用于查找文本中的关键词，而不是直接比较索引中的值。
|
||||
MyISAM 存储引擎支持全文索引，用于查找文本中的关键词，而不是直接比较索引中的值。
|
||||
|
||||
使用 MATCH AGAINST，而不是普通的 WHERE。
|
||||
使用 MATCH AGAINST，而不是普通的 WHERE。
|
||||
|
||||
## 2. 索引的优点
|
||||
## 2. 索引的优点
|
||||
|
||||
- 大大减少了服务器需要扫描的数据量；
|
||||
- 大大减少了服务器需要扫描的数据量；
|
||||
|
||||
- 帮助服务器避免进行排序和创建临时表；
|
||||
- 帮助服务器避免进行排序和创建临时表；
|
||||
|
||||
- 将随机 I/O 变为顺序 I/O。
|
||||
- 将随机 I/O 变为顺序 I/O。
|
||||
|
||||
## 3. 索引优化
|
||||
## 3. 索引优化
|
||||
|
||||
### 3.1 独立的列
|
||||
### 3.1 独立的列
|
||||
|
||||
在进行查询时，索引列不能是表达式的一部分，也不能是函数的参数，否则无法使用索引。
|
||||
在进行查询时，索引列不能是表达式的一部分，也不能是函数的参数，否则无法使用索引。
|
||||
|
||||
例如下面的查询不能使用 actor_id 列的索引：
|
||||
例如下面的查询不能使用 actor_id 列的索引：
|
||||
|
||||
```sql
|
||||
SELECT actor_id FROM sakila.actor WHERE actor_id + 1 = 5;
|
||||
```
|
||||
|
||||
### 3.2 前缀索引
|
||||
### 3.2 前缀索引
|
||||
|
||||
对于 BLOB、TEXT 和 VARCHAR 类型的列，必须使用前缀索引，只索引开始的部分字符。
|
||||
对于 BLOB、TEXT 和 VARCHAR 类型的列，必须使用前缀索引，只索引开始的部分字符。
|
||||
|
||||
对于前缀长度的选取需要根据 **索引选择性** 来确定：不重复的索引值和记录总数的比值。选择性越高，查询效率也越高。最大值为 1 ，此时每个记录都有唯一的索引与其对应。
|
||||
对于前缀长度的选取需要根据 **索引选择性** 来确定：不重复的索引值和记录总数的比值。选择性越高，查询效率也越高。最大值为 1 ，此时每个记录都有唯一的索引与其对应。
|
||||
|
||||
### 3.3 多列索引
|
||||
### 3.3 多列索引
|
||||
|
||||
在需要使用多个列作为条件进行查询时，使用多列索引比使用多个单列索引性能更好。例如下面的语句中，最好把 actor_id 和 file_id 设置为多列索引。
|
||||
在需要使用多个列作为条件进行查询时，使用多列索引比使用多个单列索引性能更好。例如下面的语句中，最好把 actor_id 和 file_id 设置为多列索引。
|
||||
|
||||
```sql
|
||||
SELECT file_id, actor_ id FROM sakila.film_actor
|
||||
WhERE actor_id = 1 OR film_id = 1;
|
||||
```
|
||||
|
||||
### 3.4 索引列的顺序
|
||||
### 3.4 索引列的顺序
|
||||
|
||||
让选择性最强的索引列放在前面，例如下面显示的结果中 customer_id 的选择性比 staff_id 更高，因此最好把 customer_id 列放在多列索引的前面。
|
||||
让选择性最强的索引列放在前面，例如下面显示的结果中 customer_id 的选择性比 staff_id 更高，因此最好把 customer_id 列放在多列索引的前面。
|
||||
|
||||
```sql
|
||||
SELECT COUNT(DISTINCT staff_id)/COUNT(*) AS staff_id_selectivity,
|
||||
|
|
@ -236,107 +258,107 @@ customer_id_selectivity: 0.0373
|
|||
COUNT(*): 16049
|
||||
```
|
||||
|
||||
### 3.5 聚簇索引
|
||||
### 3.5 聚簇索引
|
||||
|
||||
|
||||
|
||||
聚簇索引并不是一种索引类型，而是一种数据存储方式。
|
||||
聚簇索引并不是一种索引类型，而是一种数据存储方式。
|
||||
|
||||
术语“聚簇”表示数据行和相邻的键值紧密地存储在一起，InnoDB 的聚簇索引的数据行存放在 B-Tree 的叶子页中。
|
||||
术语“聚簇”表示数据行和相邻的键值紧密地存储在一起，InnoDB 的聚簇索引的数据行存放在 B-Tree 的叶子页中。
|
||||
|
||||
因为无法把数据行存放在两个不同的地方，所以一个表只能有一个聚簇索引。
|
||||
因为无法把数据行存放在两个不同的地方，所以一个表只能有一个聚簇索引。
|
||||
|
||||
**优点**
|
||||
**优点**
|
||||
|
||||
1. 可以把相关数据保存在一起，减少 I/O 操作；
|
||||
2. 因为数据保存在 B-Tree 中，因此数据访问更快。
|
||||
1. 可以把相关数据保存在一起，减少 I/O 操作；
|
||||
2. 因为数据保存在 B-Tree 中，因此数据访问更快。
|
||||
|
||||
**缺点**
|
||||
**缺点**
|
||||
|
||||
1. 聚簇索引最大限度提高了 I/O 密集型应用的性能，但是如果数据全部放在内存，就没必要用聚簇索引。
|
||||
2. 插入速度严重依赖于插入顺序，按主键的顺序插入是最快的。
|
||||
3. 更新操作代价很高，因为每个被更新的行都会移动到新的位置。
|
||||
4. 当插入到某个已满的页中，存储引擎会将该页分裂成两个页面来容纳该行，页分裂会导致表占用更多的磁盘空间。
|
||||
5. 如果行比较稀疏，或者由于页分裂导致数据存储不连续时，聚簇索引可能导致全表扫描速度变慢。
|
||||
1. 聚簇索引最大限度提高了 I/O 密集型应用的性能，但是如果数据全部放在内存，就没必要用聚簇索引。
|
||||
2. 插入速度严重依赖于插入顺序，按主键的顺序插入是最快的。
|
||||
3. 更新操作代价很高，因为每个被更新的行都会移动到新的位置。
|
||||
4. 当插入到某个已满的页中，存储引擎会将该页分裂成两个页面来容纳该行，页分裂会导致表占用更多的磁盘空间。
|
||||
5. 如果行比较稀疏，或者由于页分裂导致数据存储不连续时，聚簇索引可能导致全表扫描速度变慢。
|
||||
|
||||
### 3.6 覆盖索引
|
||||
### 3.6 覆盖索引
|
||||
|
||||
索引包含所有需要查询的字段的值。
|
||||
索引包含所有需要查询的字段的值。
|
||||
|
||||
## 4. B-Tree 和 B+Tree 原理
|
||||
## 4. B-Tree 和 B+Tree 原理
|
||||
|
||||
### 4. 1 B-Tree
|
||||
|
||||
|
||||
|
||||
为了描述 B-Tree，首先定义一条数据记录为一个二元组 [key, data]，key 为记录的键，data 为数据记录除 key 外的数据。
|
||||
为了描述 B-Tree，首先定义一条数据记录为一个二元组 [key, data]，key 为记录的键，data 为数据记录除 key 外的数据。
|
||||
|
||||
B-Tree 是满足下列条件的数据结构：
|
||||
B-Tree 是满足下列条件的数据结构：
|
||||
|
||||
- 所有叶节点具有相同的深度，也就是说 B-Tree 是平衡的；
|
||||
- 一个节点中的 key 从左到右非递减排列；
|
||||
- 如果某个指针的左右相邻 key 分别是 key<sub>i</sub> 和 key<sub>i+1</sub>，且不为 null，则该指针指向节点的所有 key 大于 key<sub>i</sub> 且小于 key<sub>i+1</sub>。
|
||||
- 所有叶节点具有相同的深度，也就是说 B-Tree 是平衡的；
|
||||
- 一个节点中的 key 从左到右非递减排列；
|
||||
- 如果某个指针的左右相邻 key 分别是 key<sub>i</sub> 和 key<sub>i+1</sub>，且不为 null，则该指针指向节点的所有 key 大于 key<sub>i</sub> 且小于 key<sub>i+1</sub>。
|
||||
|
||||
在 B-Tree 中按 key 检索数据的算法非常直观：首先从根节点进行二分查找，如果找到则返回对应节点的 data，否则对相应区间的指针指向的节点递归进行查找，直到找到节点或找到 null 指针，前者查找成功，后者查找失败。
|
||||
在 B-Tree 中按 key 检索数据的算法非常直观：首先从根节点进行二分查找，如果找到则返回对应节点的 data，否则对相应区间的指针指向的节点递归进行查找，直到找到节点或找到 null 指针，前者查找成功，后者查找失败。
|
||||
|
||||
由于插入删除新的数据记录会破坏 B-Tree 的性质，因此在插入删除时，需要对树进行一个分裂、合并、转移等操作以保持 B-Tree 性质。
|
||||
由于插入删除新的数据记录会破坏 B-Tree 的性质，因此在插入删除时，需要对树进行一个分裂、合并、转移等操作以保持 B-Tree 性质。
|
||||
|
||||
### 4.2 B+Tree
|
||||
|
||||
|
||||
|
||||
与 B-Tree 相比，B+Tree 有以下不同点：
|
||||
与 B-Tree 相比，B+Tree 有以下不同点：
|
||||
|
||||
- 每个节点的指针上限为 2d 而不是 2d+1；
|
||||
- 内节点不存储 data，只存储 key，叶子节点不存储指针。
|
||||
- 每个节点的指针上限为 2d 而不是 2d+1；
|
||||
- 内节点不存储 data，只存储 key，叶子节点不存储指针。
|
||||
|
||||
### 4.3 带有顺序访问指针的 B+Tree
|
||||
### 4.3 带有顺序访问指针的 B+Tree
|
||||
|
||||
|
||||
|
||||
一般在数据库系统或文件系统中使用的 B+Tree 结构都在经典 B+Tree 基础上进行了优化，在叶子节点增加了顺序访问指针，做这个优化的目的是为了提高区间访问的性能。
|
||||
一般在数据库系统或文件系统中使用的 B+Tree 结构都在经典 B+Tree 基础上进行了优化，在叶子节点增加了顺序访问指针，做这个优化的目的是为了提高区间访问的性能。
|
||||
|
||||
### 4.4 为什么使用 B-Tree 和 B+Tree
|
||||
### 4.4 为什么使用 B-Tree 和 B+Tree
|
||||
|
||||
红黑树等数据结构也可以用来实现索引，但是文件系统及数据库系统普遍采用 B-/+Tree 作为索引结构。
|
||||
红黑树等数据结构也可以用来实现索引，但是文件系统及数据库系统普遍采用 B-/+Tree 作为索引结构。
|
||||
|
||||
页是计算机管理存储器的逻辑块，硬件及操作系统往往将主存和磁盘存储区分割为连续的大小相等的块，每个存储块称为一页（在许多操作系统中，页得大小通常为 4k），主存和磁盘以页为单位交换数据。
|
||||
页是计算机管理存储器的逻辑块，硬件及操作系统往往将主存和磁盘存储区分割为连续的大小相等的块，每个存储块称为一页（在许多操作系统中，页得大小通常为 4k），主存和磁盘以页为单位交换数据。
|
||||
|
||||
一般来说，索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上。为了减少磁盘 I/O，磁盘往往不是严格按需读取，而是每次都会预读。这样做的理论依据是计算机科学中著名的局部性原理：当一个数据被用到时，其附近的数据也通常会马上被使用。数据库系统的设计者巧妙利用了磁盘预读原理，将一个节点的大小设为等于一个页，这样每个节点只需要一次 I/O 就可以完全载入。B-Tree 中一次检索最多需要 h-1 次 I/O（根节点常驻内存），渐进复杂度为 O(h)=O(logdN)。一般实际应用中，出度 d 是非常大的数字，通常超过 100，因此 h 非常小（通常不超过 3）。而红黑树这种结构，h 明显要深的多。并且于逻辑上很近的节点（父子）物理上可能很远，无法利用局部性，效率明显比 B-Tree 差很多。
|
||||
一般来说，索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上。为了减少磁盘 I/O，磁盘往往不是严格按需读取，而是每次都会预读。这样做的理论依据是计算机科学中著名的局部性原理：当一个数据被用到时，其附近的数据也通常会马上被使用。数据库系统的设计者巧妙利用了磁盘预读原理，将一个节点的大小设为等于一个页，这样每个节点只需要一次 I/O 就可以完全载入。B-Tree 中一次检索最多需要 h-1 次 I/O（根节点常驻内存），渐进复杂度为 O(h)=O(logdN)。一般实际应用中，出度 d 是非常大的数字，通常超过 100，因此 h 非常小（通常不超过 3）。而红黑树这种结构，h 明显要深的多。并且于逻辑上很近的节点（父子）物理上可能很远，无法利用局部性，效率明显比 B-Tree 差很多。
|
||||
|
||||
B+Tree 更适合外存索引，原因和内节点出度 d 有关。由于 B+Tree 内节点去掉了 data 域，因此可以拥有更大的出度，拥有更好的性能。
|
||||
B+Tree 更适合外存索引，原因和内节点出度 d 有关。由于 B+Tree 内节点去掉了 data 域，因此可以拥有更大的出度，拥有更好的性能。
|
||||
|
||||
# 查询性能优化
|
||||
# 查询性能优化
|
||||
|
||||
## 1. Explain
|
||||
|
||||
用来分析 SQL 语句，分析结果中比较重要的字段有：
|
||||
用来分析 SQL 语句，分析结果中比较重要的字段有：
|
||||
|
||||
- select_type : 查询类型，有简单查询、联合查询和子查询
|
||||
- select_type : 查询类型，有简单查询、联合查询和子查询
|
||||
|
||||
- key : 使用的索引
|
||||
- key : 使用的索引
|
||||
|
||||
- rows : 扫描的行数
|
||||
- rows : 扫描的行数
|
||||
|
||||
## 2. 减少返回的列
|
||||
## 2. 减少返回的列
|
||||
|
||||
慢查询主要是因为访问了过多数据，除了访问过多行之外，也包括访问过多列。
|
||||
慢查询主要是因为访问了过多数据，除了访问过多行之外，也包括访问过多列。
|
||||
|
||||
最好不要使用 SELECT * 语句，要根据需要选择查询的列。
|
||||
最好不要使用 SELECT * 语句，要根据需要选择查询的列。
|
||||
|
||||
## 3. 减少返回的行
|
||||
## 3. 减少返回的行
|
||||
|
||||
最好使用 LIMIT 语句来取出想要的那些行。
|
||||
最好使用 LIMIT 语句来取出想要的那些行。
|
||||
|
||||
还可以建立索引来减少条件语句的全表扫描。例如对于下面的语句，不适用索引的情况下需要进行全表扫描，而使用索引只需要扫描几行记录即可，使用 Explain 语句可以通过观察 rows 字段来看出这种差异。
|
||||
还可以建立索引来减少条件语句的全表扫描。例如对于下面的语句，不适用索引的情况下需要进行全表扫描，而使用索引只需要扫描几行记录即可，使用 Explain 语句可以通过观察 rows 字段来看出这种差异。
|
||||
|
||||
```sql
|
||||
SELECT * FROM sakila.film_actor WHERE film_id = 1;
|
||||
```
|
||||
|
||||
## 4. 拆分大的 DELETE 或 INSERT 语句
|
||||
## 4. 拆分大的 DELETE 或 INSERT 语句
|
||||
|
||||
如果一次性执行的话，可能一次锁住很多数据、占满整个事务日志、耗尽系统资源、阻塞很多小的但重要的查询。
|
||||
如果一次性执行的话，可能一次锁住很多数据、占满整个事务日志、耗尽系统资源、阻塞很多小的但重要的查询。
|
||||
|
||||
```sql
|
||||
DELEFT FROM messages WHERE create < DATE_SUB(NOW(), INTERVAL 3 MONTH);
|
||||
|
|
@ -349,74 +371,74 @@ do {
|
|||
} while rows_affected > 0
|
||||
```
|
||||
|
||||
# 分库与分表
|
||||
# 分库与分表
|
||||
|
||||
**1. 分表与分区的不同**
|
||||
**1. 分表与分区的不同**
|
||||
|
||||
分表，就是讲一张表分成多个小表，这些小表拥有不同的表名；而分区是将一张表的数据分为多个区块，这些区块可以存储在同一个磁盘上，也可以存储在不同的磁盘上，这种方式下表仍然只有一个。
|
||||
分表，就是讲一张表分成多个小表，这些小表拥有不同的表名；而分区是将一张表的数据分为多个区块，这些区块可以存储在同一个磁盘上，也可以存储在不同的磁盘上，这种方式下表仍然只有一个。
|
||||
|
||||
**2. 使用分库与分表的原因**
|
||||
**2. 使用分库与分表的原因**
|
||||
|
||||
随着时间和业务的发展，数据库中的表会越来越多，并且表中的数据量也会越来越大，那么读写操作的开销也会随着增大。
|
||||
随着时间和业务的发展，数据库中的表会越来越多，并且表中的数据量也会越来越大，那么读写操作的开销也会随着增大。
|
||||
|
||||
**3. 垂直切分**
|
||||
**3. 垂直切分**
|
||||
|
||||
将表按功能模块、关系密切程度划分出来，部署到不同的库上。例如，我们会建立商品数据库 payDB、用户数据库 userDB 等，分别用来存储项目与商品有关的表和与用户有关的表。
|
||||
将表按功能模块、关系密切程度划分出来，部署到不同的库上。例如，我们会建立商品数据库 payDB、用户数据库 userDB 等，分别用来存储项目与商品有关的表和与用户有关的表。
|
||||
|
||||
**4. 水平切分**
|
||||
**4. 水平切分**
|
||||
|
||||
把表中的数据按照某种规则存储到多个结构相同的表中，例如按 id 的散列值、性别等进行划分，
|
||||
把表中的数据按照某种规则存储到多个结构相同的表中，例如按 id 的散列值、性别等进行划分，
|
||||
|
||||
**5. 垂直切分与水平切分的选择**
|
||||
**5. 垂直切分与水平切分的选择**
|
||||
|
||||
如果数据库中的表太多，并且项目各项业务逻辑清晰，那么垂直切分是首选。
|
||||
如果数据库中的表太多，并且项目各项业务逻辑清晰，那么垂直切分是首选。
|
||||
|
||||
如果数据库的表不多，但是单表的数据量很大，应该选择水平切分。
|
||||
如果数据库的表不多，但是单表的数据量很大，应该选择水平切分。
|
||||
|
||||
**6. 水平切分的实现方式**
|
||||
**6. 水平切分的实现方式**
|
||||
|
||||
最简单的是使用 merge 存储引擎。
|
||||
最简单的是使用 merge 存储引擎。
|
||||
|
||||
**7. 分库与分表存在的问题**
|
||||
**7. 分库与分表存在的问题**
|
||||
|
||||
(1) 事务问题
|
||||
(1) 事务问题
|
||||
|
||||
在执行分库分表之后，由于数据存储到了不同的库上，数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。
|
||||
在执行分库分表之后，由于数据存储到了不同的库上，数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。
|
||||
|
||||
(2) 跨库跨表连接问题
|
||||
(2) 跨库跨表连接问题
|
||||
|
||||
在执行了分库分表之后，难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上。这时，表的连接操作将受到限制，我们无法连接位于不同分库的表，也无法连接分表粒度不同的表，导致原本只需要一次查询就能够完成的业务需要进行多次才能完成。
|
||||
在执行了分库分表之后，难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上。这时，表的连接操作将受到限制，我们无法连接位于不同分库的表，也无法连接分表粒度不同的表，导致原本只需要一次查询就能够完成的业务需要进行多次才能完成。
|
||||
|
||||
# 故障转移和故障恢复
|
||||
# 故障转移和故障恢复
|
||||
|
||||
故障转移也叫做切换，当主库出现故障时就切换到备库，使备库成为主库。故障恢复顾名思义就是从故障中恢复过来，并且保证数据的正确性。
|
||||
故障转移也叫做切换，当主库出现故障时就切换到备库，使备库成为主库。故障恢复顾名思义就是从故障中恢复过来，并且保证数据的正确性。
|
||||
|
||||
## 1. 故障转移
|
||||
## 1. 故障转移
|
||||
|
||||
**1.1 提升备库或切换角色**
|
||||
**1.1 提升备库或切换角色**
|
||||
|
||||
提升一台备库为主库，或者在一个主-主复制结构中调整主动和被动角色。
|
||||
提升一台备库为主库，或者在一个主-主复制结构中调整主动和被动角色。
|
||||
|
||||
**1.2 虚拟 IP 地址和 IP 托管**
|
||||
**1.2 虚拟 IP 地址和 IP 托管**
|
||||
|
||||
为 MySQL 实例指定一个逻辑 IP 地址，当 MySQL 实例失效时，可以将 IP 地址转移到另一台 MySQL 服务器上。
|
||||
为 MySQL 实例指定一个逻辑 IP 地址，当 MySQL 实例失效时，可以将 IP 地址转移到另一台 MySQL 服务器上。
|
||||
|
||||
**1.3 中间件解决方案**
|
||||
**1.3 中间件解决方案**
|
||||
|
||||
通过代理，可以路由流量到可以使用的服务器上。
|
||||
通过代理，可以路由流量到可以使用的服务器上。
|
||||
|
||||
|
||||
|
||||
**1.4 在应用中处理故障转移**
|
||||
**1.4 在应用中处理故障转移**
|
||||
|
||||
将故障转移整合到应用中可能导致应用变得太过笨拙。
|
||||
将故障转移整合到应用中可能导致应用变得太过笨拙。
|
||||
|
||||
## 2. 故障恢复
|
||||
## 2. 故障恢复
|
||||
|
||||
|
||||
# 参考资料
|
||||
# 参考资料
|
||||
|
||||
- 高性能 MySQL
|
||||
- [MySQL 索引背后的数据结构及算法原理 ](http://blog.codinglabs.org/articles/theory-of-mysql-index.html)
|
||||
- [MySQL 索引优化全攻略 ](http://www.runoob.com/w3cnote/mysql-index.html)
|
||||
- [20+ 条 MySQL 性能优化的最佳经验 ](https://www.jfox.info/20-tiao-mysql-xing-nen-you-hua-de-zui-jia-jing-yan.html)
|
||||
- 高性能 MySQL
|
||||
- [MySQL 索引背后的数据结构及算法原理 ](http://blog.codinglabs.org/articles/theory-of-mysql-index.html)
|
||||
- [MySQL 索引优化全攻略 ](http://www.runoob.com/w3cnote/mysql-index.html)
|
||||
- [20+ 条 MySQL 性能优化的最佳经验 ](https://www.jfox.info/20-tiao-mysql-xing-nen-you-hua-de-zui-jia-jing-yan.html)
|
||||
|
|
|
|||
206
notes/算法.md
206
notes/算法.md
|
|
@ -18,63 +18,63 @@
|
|||
* [5. 各种 union-find 算法的比较](#5-各种-union-find-算法的比较)
|
||||
* [第二章 排序](#第二章-排序)
|
||||
* [初级排序算法](#初级排序算法)
|
||||
* [约定](#约定)
|
||||
* [选择排序](#选择排序)
|
||||
* [插入排序](#插入排序)
|
||||
* [选择排序和插入排序的比较](#选择排序和插入排序的比较)
|
||||
* [希尔排序](#希尔排序)
|
||||
* [1. 约定](#1-约定)
|
||||
* [2. 选择排序](#2-选择排序)
|
||||
* [3. 插入排序](#3-插入排序)
|
||||
* [4. 选择排序和插入排序的比较](#4-选择排序和插入排序的比较)
|
||||
* [5. 希尔排序](#5-希尔排序)
|
||||
* [归并排序](#归并排序)
|
||||
* [归并方法](#归并方法)
|
||||
* [自顶向下归并排序](#自顶向下归并排序)
|
||||
* [自底向上归并排序](#自底向上归并排序)
|
||||
* [1. 归并方法](#1-归并方法)
|
||||
* [2. 自顶向下归并排序](#2-自顶向下归并排序)
|
||||
* [3. 自底向上归并排序](#3-自底向上归并排序)
|
||||
* [快速排序](#快速排序)
|
||||
* [基本算法](#基本算法)
|
||||
* [切分](#切分)
|
||||
* [性能分析](#性能分析)
|
||||
* [算法改进](#算法改进)
|
||||
* [切换到插入排序](#切换到插入排序)
|
||||
* [三取样](#三取样)
|
||||
* [三向切分](#三向切分)
|
||||
* [1. 基本算法](#1-基本算法)
|
||||
* [2. 切分](#2-切分)
|
||||
* [3. 性能分析](#3-性能分析)
|
||||
* [4. 算法改进](#4-算法改进)
|
||||
* [4.1 切换到插入排序](#41-切换到插入排序)
|
||||
* [4.2 三取样](#42-三取样)
|
||||
* [4.3 三向切分](#43-三向切分)
|
||||
* [优先队列](#优先队列)
|
||||
* [堆](#堆)
|
||||
* [上浮和下沉](#上浮和下沉)
|
||||
* [插入元素](#插入元素)
|
||||
* [删除最大元素](#删除最大元素)
|
||||
* [堆排序](#堆排序)
|
||||
* [分析](#分析)
|
||||
* [1. 堆](#1-堆)
|
||||
* [2. 上浮和下沉](#2-上浮和下沉)
|
||||
* [3. 插入元素](#3-插入元素)
|
||||
* [4. 删除最大元素](#4-删除最大元素)
|
||||
* [5. 堆排序](#5-堆排序)
|
||||
* [6. 分析](#6-分析)
|
||||
* [应用](#应用)
|
||||
* [排序算法的比较](#排序算法的比较)
|
||||
* [Java 的排序算法实现](#java-的排序算法实现)
|
||||
* [基于切分的快速选择算法](#基于切分的快速选择算法)
|
||||
* [1. 排序算法的比较](#1-排序算法的比较)
|
||||
* [2. Java 的排序算法实现](#2-java-的排序算法实现)
|
||||
* [3. 基于切分的快速选择算法](#3-基于切分的快速选择算法)
|
||||
* [第三章 查找](#第三章-查找)
|
||||
* [符号表](#符号表)
|
||||
* [API](#api)
|
||||
* [有序符号表](#有序符号表)
|
||||
* [无序链表实现](#无序链表实现)
|
||||
* [有序数组的二分查找](#有序数组的二分查找)
|
||||
* [对二分查找的分析](#对二分查找的分析)
|
||||
* [1. API](#1-api)
|
||||
* [2. 有序符号表](#2-有序符号表)
|
||||
* [3. 无序链表实现](#3-无序链表实现)
|
||||
* [4. 有序数组的二分查找](#4-有序数组的二分查找)
|
||||
* [5. 对二分查找的分析](#5-对二分查找的分析)
|
||||
* [二叉查找树](#二叉查找树)
|
||||
* [get()](#get)
|
||||
* [put()](#put)
|
||||
* [分析](#分析)
|
||||
* [floor()](#floor)
|
||||
* [rank()](#rank)
|
||||
* [min()](#min)
|
||||
* [deleteMin()](#deletemin)
|
||||
* [delete()](#delete)
|
||||
* [keys()](#keys)
|
||||
* [性能分析](#性能分析)
|
||||
* [1. get()](#1-get)
|
||||
* [2. put()](#2-put)
|
||||
* [3. 分析](#3-分析)
|
||||
* [4. floor()](#4-floor)
|
||||
* [5. rank()](#5-rank)
|
||||
* [6. min()](#6-min)
|
||||
* [7. deleteMin()](#7-deletemin)
|
||||
* [8. delete()](#8-delete)
|
||||
* [9. keys()](#9-keys)
|
||||
* [10. 性能分析](#10-性能分析)
|
||||
* [平衡查找树](#平衡查找树)
|
||||
* [2-3 查找树](#2-3-查找树)
|
||||
* [插入操作](#插入操作)
|
||||
* [性质](#性质)
|
||||
* [1. 插入操作](#1-插入操作)
|
||||
* [2. 性质](#2-性质)
|
||||
* [红黑二叉查找树](#红黑二叉查找树)
|
||||
* [左旋转](#左旋转)
|
||||
* [右旋转](#右旋转)
|
||||
* [颜色转换](#颜色转换)
|
||||
* [插入](#插入)
|
||||
* [删除最小键](#删除最小键)
|
||||
* [分析](#分析)
|
||||
* [1. 左旋转](#1-左旋转)
|
||||
* [2. 右旋转](#2-右旋转)
|
||||
* [3. 颜色转换](#3-颜色转换)
|
||||
* [4. 插入](#4-插入)
|
||||
* [5. 删除最小键](#5-删除最小键)
|
||||
* [6. 分析](#6-分析)
|
||||
* [散列表](#散列表)
|
||||
* [散列函数](#散列函数)
|
||||
* [基于拉链法的散列表](#基于拉链法的散列表)
|
||||
|
|
@ -96,12 +96,10 @@
|
|||
|
||||
### 1. 数组实现
|
||||
|
||||
|
||||
```java
|
||||
public class ResizeArrayStack<Item> implements Iterable<Item> {
|
||||
|
||||
// 需要用 Object 数组然后转型，不能直接使用 new Item[1];
|
||||
private Item[] a = (Item[]) new Object[1];
|
||||
// 栈中的元素个数
|
||||
private int N = 0;
|
||||
|
||||
public void push(Item item) {
|
||||
|
|
@ -158,6 +156,12 @@ public class ResizeArrayStack<Item> implements Iterable<Item> {
|
|||
}
|
||||
```
|
||||
|
||||
上面实现使用了泛型，Java 不能直接创建泛型数组，只能使用转型来创建。
|
||||
|
||||
```java
|
||||
Item[] arr = (Item[]) new Object[N];
|
||||
```
|
||||
|
||||
### 2. 链表实现
|
||||
|
||||
需要使用链表的头插法来实现，因为头插法中最后压入栈的元素在链表的开头，它的 next 指针指向前一个压入栈的元素，在弹出元素使就可以让前一个压入栈的元素称为栈顶元素。
|
||||
|
|
@ -497,7 +501,7 @@ public class WeightedQuickUnionUF {
|
|||
|
||||
## 初级排序算法
|
||||
|
||||
### 约定
|
||||
### 1. 约定
|
||||
|
||||
待排序的元素需要实现 Java 的 Comparable 接口，该接口有 compareTo() 方法。
|
||||
|
||||
|
|
@ -517,7 +521,7 @@ private void exch(Comparable[] a, int i, int j){
|
|||
}
|
||||
```
|
||||
|
||||
### 选择排序
|
||||
### 2. 选择排序
|
||||
|
||||
找到数组中的最小元素，然后将它与数组的第一个元素交换位置。然后再从剩下的元素中找到最小的元素，将它与数组的第二个元素交换位置。不断进行这样的操作，直到将整个数组排序。
|
||||
|
||||
|
|
@ -540,7 +544,7 @@ public class Selection {
|
|||
|
||||
选择排序需要 \~N<sup>2</sup>/2 次比较和 \~N 次交换，它的运行时间与输入无关，这个特点使得它对一个已经排序的数组也需要这么多的比较和交换操作。
|
||||
|
||||
### 插入排序
|
||||
### 3. 插入排序
|
||||
|
||||
将一个元素插入到已排序的数组中，使得插入之后的数组也是有序的。插入排序从左到右插入每个元素，每次插入之后左部的子数组是有序的。
|
||||
|
||||
|
|
@ -563,11 +567,11 @@ public class Insertion {
|
|||
|
||||
插入排序对于部分有序数组和小规模数组特别高效。
|
||||
|
||||
### 选择排序和插入排序的比较
|
||||
### 4. 选择排序和插入排序的比较
|
||||
|
||||
对于随机排序的无重复主键的数组，插入排序和选择排序的运行时间是平方级别的，两者之比是一个较小的常数。
|
||||
|
||||
### 希尔排序
|
||||
### 5. 希尔排序
|
||||
|
||||
对于大规模的数组，插入排序很慢，因为它只能交换相邻的元素，如果要把元素从一端移到另一端，就需要很多次操作。
|
||||
|
||||
|
|
@ -605,7 +609,7 @@ public class Shell {
|
|||
|
||||
|
||||
|
||||
### 归并方法
|
||||
### 1. 归并方法
|
||||
|
||||
```java
|
||||
public class MergeSort {
|
||||
|
|
@ -628,7 +632,7 @@ public class MergeSort {
|
|||
}
|
||||
```
|
||||
|
||||
### 自顶向下归并排序
|
||||
### 2. 自顶向下归并排序
|
||||
|
||||
```java
|
||||
public static void sort(Comparable[] a) {
|
||||
|
|
@ -653,7 +657,7 @@ public class MergeSort {
|
|||
|
||||
因为小数组的递归操作会过于频繁，因此使用插入排序来处理小数组将会获得更高的性能。
|
||||
|
||||
### 自底向上归并排序
|
||||
### 3. 自底向上归并排序
|
||||
|
||||
先归并那些微型数组，然后成对归并得到的子数组。
|
||||
|
||||
|
|
@ -673,7 +677,7 @@ public class MergeSort {
|
|||
|
||||
## 快速排序
|
||||
|
||||
### 基本算法
|
||||
### 1. 基本算法
|
||||
|
||||
归并排序将数组分为两个子数组分别排序，并将有序的子数组归并使得整个数组排序；快速排序通过一个切分元素将数组分为两个子数组，左子数组小于等于切分元素，右子数组大于等于切分元素，将这两个子数组排序也就将整个数组排序了。
|
||||
|
||||
|
|
@ -695,7 +699,7 @@ public class QuickSort {
|
|||
}
|
||||
```
|
||||
|
||||
### 切分
|
||||
### 2. 切分
|
||||
|
||||
取 a[lo] 作为切分元素，然后从数组的左端向右扫描直到找到第一个大于等于它的元素，再从数组的右端向左扫描找到第一个小于等于它的元素，交换这两个元素，并不断继续这个过程，就可以保证左指针的左侧元素都不大于切分元素，右指针 j 的右侧元素都不小于切分元素。当两个指针相遇时，将切分元素 a[lo] 和左子数组最右侧的元素 a[j] 交换然后返回 j 即可。
|
||||
|
||||
|
|
@ -716,7 +720,7 @@ public class QuickSort {
|
|||
}
|
||||
```
|
||||
|
||||
### 性能分析
|
||||
### 3. 性能分析
|
||||
|
||||
快速排序是原地排序，不需要辅助数组，但是递归调用需要辅助栈。
|
||||
|
||||
|
|
@ -724,17 +728,17 @@ public class QuickSort {
|
|||
|
||||
最坏的情况下，第一次从最小的元素切分，第二次从第二小的元素切分，如此这般。因此最坏的情况下需要比较 N<sup>2</sup>/2。为了防止数组最开始就是有序的，在进行快速排序时需要随机打乱数组。
|
||||
|
||||
### 算法改进
|
||||
### 4. 算法改进
|
||||
|
||||
#### 切换到插入排序
|
||||
#### 4.1 切换到插入排序
|
||||
|
||||
因为快速排序在小数组中也会调用自己，对于小数组，插入排序比快速排序的性能更好，因此在小数组中可以切换到插入排序。
|
||||
|
||||
#### 三取样
|
||||
#### 4.2 三取样
|
||||
|
||||
最好的情况下是每次都能取数组的中位数作为切分元素，但是计算中位数的代价很高。人们发现取 3 个元素并将大小居中的元素作为切分元素的效果最好。
|
||||
|
||||
#### 三向切分
|
||||
#### 4.3 三向切分
|
||||
|
||||
对于有大量重复元素的数组，可以将数组切分为三部分，分别对应小于、等于和大于切分元素。
|
||||
|
||||
|
|
@ -764,7 +768,7 @@ public class Quick3Way {
|
|||
|
||||
优先队列主要用于处理最大元素。
|
||||
|
||||
### 堆
|
||||
### 1. 堆
|
||||
|
||||
定义：一颗二叉树的每个节点都大于等于它的两个子节点。
|
||||
|
||||
|
|
@ -801,7 +805,7 @@ public class MaxPQ<Key extends Comparable<Key> {
|
|||
}
|
||||
```
|
||||
|
||||
### 上浮和下沉
|
||||
### 2. 上浮和下沉
|
||||
|
||||
在堆中，当一个节点比父节点大，那么需要交换这个两个节点。交换后还可能比它新的父节点大，因此需要不断地进行比较和交换操作。把这种操作称为上浮。
|
||||
|
||||
|
|
@ -828,7 +832,7 @@ private void sink(int k) {
|
|||
}
|
||||
```
|
||||
|
||||
### 插入元素
|
||||
### 3. 插入元素
|
||||
|
||||
将新元素放到数组末尾，然后上浮到合适的位置。
|
||||
|
||||
|
|
@ -839,7 +843,7 @@ public void insert(Key v) {
|
|||
}
|
||||
```
|
||||
|
||||
### 删除最大元素
|
||||
### 4. 删除最大元素
|
||||
|
||||
从数组顶端删除最大的元素，并将数组的最后一个元素放到顶端，并让这个元素下沉到合适的位置。
|
||||
|
||||
|
|
@ -853,9 +857,9 @@ public Key delMax() {
|
|||
}
|
||||
```
|
||||
|
||||
### 堆排序
|
||||
### 5. 堆排序
|
||||
|
||||
由于堆可以很容易得到最大的元素并删除它，不断地进行这种操作可以得到一个递减序列。如果把最大元素和当前堆中数组的最后一个元素交换位置，并且不删除它，那么就可以得到一个从尾到头的递减序列，从正向来看就是一个递增序列。因此很容易使用堆来进行排序，并且堆排序是原地排序，不占用额外空间。
|
||||
由于堆可以很容易得到最大的元素并删除它，不断地进行这种操作可以得到一个递减序列。如果把最大元素和当前堆中数组的最后一个元素交换位置，并且不删除它，那么就可以得到一个从尾到头的递减序列，从正向来看就是一个递增序列。因此很容易使用堆来进行排序，并且堆排序是原地排序，不占用额外空间。
|
||||
|
||||
堆排序要分两个阶段，第一个阶段是把无序数组建立一个堆；第二个阶段是交换最大元素和当前堆的数组最后一个元素，并且进行下沉操作维持堆的有序状态。
|
||||
|
||||
|
|
@ -876,7 +880,7 @@ public static void sort(Comparable[] a){
|
|||
}
|
||||
```
|
||||
|
||||
### 分析
|
||||
### 6. 分析
|
||||
|
||||
一个堆的高度为 lgN，因此在堆中插入元素和删除最大元素的复杂度都为 lgN。
|
||||
|
||||
|
|
@ -888,17 +892,17 @@ public static void sort(Comparable[] a){
|
|||
|
||||
## 应用
|
||||
|
||||
### 排序算法的比较
|
||||
### 1. 排序算法的比较
|
||||
|
||||
|
||||
|
||||
快速排序时最快的通用排序算法，它的内循环的指令很少，而且它还能利用缓存，因为它总是顺序地访问数据。它的运行时间增长数量级为 $\~cNlgN$，这里的 c 比其他线性对数级别的排序算法都要小。使用三向切分之后，实际应用中可能出现的某些分布的输入能够达到 线性级别，而其它排序算法仍然需要线性对数时间。
|
||||
快速排序时最快的通用排序算法，它的内循环的指令很少，而且它还能利用缓存，因为它总是顺序地访问数据。它的运行时间增长数量级为 \~cNlgN，这里的 c 比其他线性对数级别的排序算法都要小。使用三向切分之后，实际应用中可能出现的某些分布的输入能够达到线性级别，而其它排序算法仍然需要线性对数时间。
|
||||
|
||||
### Java 的排序算法实现
|
||||
### 2. Java 的排序算法实现
|
||||
|
||||
Java 系统库中的主要排序方法为 java.util.Arrays.sort()，对于原始数据类型使用三向切分的快速排序，对于引用类型使用归并排序。
|
||||
|
||||
### 基于切分的快速选择算法
|
||||
### 3. 基于切分的快速选择算法
|
||||
|
||||
快速排序的 partition() 方法，会将数组的 a[lo] 至 a[hi] 重新排序并返回一个整数 j 使得 a[lo..j-1] 小于等于 a[j]，且 a[j+1..hi] 大于等于 a[j]。那么如果 j=k，a[j] 就是第 k 个数。
|
||||
|
||||
|
|
@ -917,20 +921,19 @@ Java ϵͳ
|
|||
}
|
||||
```
|
||||
|
||||
|
||||
# 第三章 查找
|
||||
|
||||
本章使用三种经典的数据类型来实现高效的符号表：二叉查找树、红黑树和散列表。
|
||||
|
||||
## 符号表
|
||||
|
||||
### API
|
||||
### 1. API
|
||||
|
||||
|
||||
|
||||
当一个键的值为 null 时，表示不存在这个键，因此可以使用 put(key, null) 作为 delete(key) 的一种延迟实现。
|
||||
|
||||
### 有序符号表
|
||||
### 2. 有序符号表
|
||||
|
||||
|
||||
|
||||
|
|
@ -938,11 +941,11 @@ Java ϵͳ
|
|||
|
||||
查找的成本模型：键的比较次数，在不进行比较时使用数组的访问次数。
|
||||
|
||||
### 无序链表实现
|
||||
### 3. 无序链表实现
|
||||
|
||||
复杂度：向一个空表中插入 N 个不同的键需要 \~N<sup>2</sup>/2 次比较。
|
||||
|
||||
### 有序数组的二分查找
|
||||
### 4. 有序数组的二分查找
|
||||
|
||||
使用一对平行数组，一个存储键一个存储值。
|
||||
|
||||
|
|
@ -1007,7 +1010,7 @@ public class BinarySearchST<Key extends Comparable<Key>, Value> {
|
|||
}
|
||||
```
|
||||
|
||||
### 对二分查找的分析
|
||||
### 5. 对二分查找的分析
|
||||
|
||||
复杂度：二分查找最多需要 lgN+1 次比较，使用二分查找实现的符号表的查找操作所需要的时间最多是对数级别的。但是插入操作需要移动数组元素，是线性级别的。
|
||||
|
||||
|
|
@ -1027,7 +1030,8 @@ public class BST<Key extends Comparable<Key>, Value> {
|
|||
private Key key;
|
||||
private Value val;
|
||||
private Node left, right;
|
||||
private int N; // 以该节点为根的子树中节点总数
|
||||
// 以该节点为根的子树中节点总数
|
||||
private int N;
|
||||
|
||||
public Node(Key key, Value val, int N) {
|
||||
this.key = key;
|
||||
|
|
@ -1047,7 +1051,7 @@ public class BST<Key extends Comparable<Key>, Value> {
|
|||
}
|
||||
```
|
||||
|
||||
### get()
|
||||
### 1. get()
|
||||
|
||||
如果树是空的，则查找未命中；如果被查找的键和根节点的键相等，查找命中，否则递归地在子树中查找：如果被查找的键较小就在左子树中查找，较大就在右子树中查找。
|
||||
|
||||
|
|
@ -1064,7 +1068,7 @@ private Value get(Node x, Key key) {
|
|||
}
|
||||
```
|
||||
|
||||
### put()
|
||||
### 2. put()
|
||||
|
||||
当插入的键不存在于树中，需要创建一个新节点，并且更新上层节点的链接使得该节点正确链接到树中。
|
||||
|
||||
|
|
@ -1083,7 +1087,7 @@ private Node put(Node x, Key key, Value val) {
|
|||
}
|
||||
```
|
||||
|
||||
### 分析
|
||||
### 3. 分析
|
||||
|
||||
二叉查找树的算法运行时间取决于树的形状，而树的形状又取决于键被插入的先后顺序。最好的情况下树是完全平衡的，每条空链接和根节点的距离都为 lgN。在最坏的情况下，树的高度为 N。
|
||||
|
||||
|
|
@ -1091,7 +1095,7 @@ private Node put(Node x, Key key, Value val) {
|
|||
|
||||
复杂度：查找和插入操作都为对数级别。
|
||||
|
||||
### floor()
|
||||
### 4. floor()
|
||||
|
||||
如果 key 小于根节点的 key，那么小于等于 key 的最大键节点一定在左子树中；如果 key 大于根节点的 key，只有当根节点右子树中存在小于等于 key 的节点，小于等于 key 的最大键节点才在右子树中，否则根节点就是小于等于 key 的最大键节点。
|
||||
|
||||
|
|
@ -1115,7 +1119,7 @@ private Node floor(Node x, Key key) {
|
|||
}
|
||||
```
|
||||
|
||||
### rank()
|
||||
### 5. rank()
|
||||
|
||||
```java
|
||||
public int rank(Key key) {
|
||||
|
|
@ -1130,7 +1134,7 @@ private int rank(Key key, Node x) {
|
|||
}
|
||||
```
|
||||
|
||||
### min()
|
||||
### 6. min()
|
||||
|
||||
```java
|
||||
private Node min(Node x) {
|
||||
|
|
@ -1139,7 +1143,7 @@ private Node min(Node x) {
|
|||
}
|
||||
```
|
||||
|
||||
### deleteMin()
|
||||
### 7. deleteMin()
|
||||
|
||||
令指向最小节点的链接指向最小节点的右子树。
|
||||
|
||||
|
|
@ -1157,7 +1161,7 @@ public Node deleteMin(Node x) {
|
|||
}
|
||||
```
|
||||
|
||||
### delete()
|
||||
### 8. delete()
|
||||
|
||||
如果待删除的节点只有子树，那么只需要让指向节点的链接指向唯一的子树即可；否则，让右子树的最小节点替换该节点。
|
||||
|
||||
|
|
@ -1185,7 +1189,7 @@ private Node delete(Node x, Key key) {
|
|||
}
|
||||
```
|
||||
|
||||
### keys()
|
||||
### 9. keys()
|
||||
|
||||
利用二叉查找树中序遍历的结果为有序序列的特点。
|
||||
|
||||
|
|
@ -1205,7 +1209,7 @@ private void keys(Node x, Queue<Key> queue, Key lo, Key hi) {
|
|||
}
|
||||
```
|
||||
|
||||
### 性能分析
|
||||
### 10. 性能分析
|
||||
|
||||
复杂度：二叉查找树所有操作在最坏的情况下所需要的时间都和树的高度成正比。
|
||||
|
||||
|
|
@ -1217,13 +1221,13 @@ private void keys(Node x, Queue<Key> queue, Key lo, Key hi) {
|
|||
|
||||
一颗完美平衡的 2-3 查找树的所有空链接到根节点的距离应该是相同的。
|
||||
|
||||
#### 插入操作
|
||||
#### 1. 插入操作
|
||||
|
||||
当插入之后产生一个临时 4- 节点时，需要将 4- 节点分裂成 3 个 2- 节点，并将中间的 2- 节点移到上层节点中，如果上移操作继续产生临时 4- 节点则一直进行分裂上移，直到不存在临时 4- 节点。
|
||||
|
||||
|
||||
|
||||
#### 性质
|
||||
#### 2. 性质
|
||||
|
||||
2-3 查找树插入操作的变换都是局部的，除了相关的节点和链接之外不必修改或者检查树的其它部分，而这些局部变换不会影响树的全局有序性和平衡性。
|
||||
|
||||
|
|
@ -1272,7 +1276,7 @@ public class RedBlackBST<Key extends Comparable<Key>, Value> {
|
|||
}
|
||||
```
|
||||
|
||||
#### 左旋转
|
||||
#### 1. 左旋转
|
||||
|
||||
因为合法的红链接都为左链接，如果出现右链接为红链接，那么就需要进行左旋转操作。
|
||||
|
||||
|
|
@ -1293,7 +1297,7 @@ public Node rotateLeft(Node h) {
|
|||
}
|
||||
```
|
||||
|
||||
#### 右旋转
|
||||
#### 2. 右旋转
|
||||
|
||||
进行右旋转是为了转换两个连续的左红链接，这会在之后的插入过程中探讨。
|
||||
|
||||
|
|
@ -1313,7 +1317,7 @@ public Node rotateRight(Node h) {
|
|||
}
|
||||
```
|
||||
|
||||
#### 颜色转换
|
||||
#### 3. 颜色转换
|
||||
|
||||
一个 4- 节点在红黑树中表现为一个节点的左右子节点都是红色的。分裂 4- 节点除了需要将子节点的颜色由红变黑之外，同时需要将父节点的颜色由黑变红，从 2-3 树的角度看就是将中间节点移到上层节点。
|
||||
|
||||
|
|
@ -1329,7 +1333,7 @@ void flipColors(Node h){
|
|||
}
|
||||
```
|
||||
|
||||
#### 插入
|
||||
#### 4. 插入
|
||||
|
||||
插入算法：
|
||||
|
||||
|
|
@ -1365,7 +1369,7 @@ private Node put(Node x, Key key, Value val) {
|
|||
|
||||
根节点一定为黑色，因为根节点没有上层节点，也就没有上层节点的左链接指向根节点。flipColors() 有可能会使得根节点的颜色变为红色，每当根节点由红色变成黑色时树的黑链接高度加 1.
|
||||
|
||||
#### 删除最小键
|
||||
#### 5. 删除最小键
|
||||
|
||||
如果最小键在一个 2- 节点中，那么删除该键会留下一个空链接，就破坏了平衡性，因此要确保最小键不在 2- 节点中。将 2- 节点转换成 3- 节点或者 4- 节点有两种方法，一种是向上层节点拿一个 key，或者向兄弟节点拿一个 key。如果上层节点是 2- 节点，那么就没办法从上层节点拿 key 了，因此要保证删除路径上的所有节点都不是 2- 节点。在向下删除的过程中，保证以下情况之一发生：
|
||||
|
||||
|
|
@ -1379,7 +1383,7 @@ private Node put(Node x, Key key, Value val) {
|
|||
|
||||
|
||||
|
||||
#### 分析
|
||||
#### 6. 分析
|
||||
|
||||
一颗大小为 N 的红黑树的高度不会超过 2lgN。最坏的情况下是它所对应的 2-3 树中构成最左边的路径节点全部都是 3- 节点而其余都是 2- 节点。
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user