diff --git a/DB.md b/DB.md index c688e0a..7fd57da 100644 --- a/DB.md +++ b/DB.md @@ -33,7 +33,7 @@ 参考视频：https://www.bilibili.com/video/BV1zJ411M7TB -参考文章：https://time.geekbang.org/column/intro/139 +参考专栏：https://time.geekbang.org/column/intro/139 参考书籍：https://book.douban.com/subject/35231266/ @@ -127,205 +127,6 @@ MySQL 配置： -*** - - - -### 常用工具 - -#### mysql - -mysql 不是指 mysql 服务，而是指 mysql 的客户端工具 - -```sh -mysql [options] [database] -``` - -* -u --user=name：指定用户名 -* -p --password[=name]：指定密码 -* -h --host=name：指定服务器IP或域名 -* -P --port=#：指定连接端口 -* -e --execute=name：执行SQL语句并退出，在控制台执行SQL语句，而不用连接到数据库执行 - -示例： - -```sh -mysql -h 127.0.0.1 -P 3306 -u root -p -mysql -uroot -p2143 db01 -e "select * from tb_book"; -``` - - - -*** - - - -#### admin - -mysqladmin 是一个执行管理操作的客户端程序，用来检查服务器的配置和当前状态、创建并删除数据库等 - -通过 `mysqladmin --help` 指令查看帮助文档 - -```sh -mysqladmin -uroot -p2143 create 'test01'; -``` - - - -*** - - - -#### binlog - -服务器生成的日志文件以二进制格式保存，如果需要检查这些文本，就要使用 mysqlbinlog 日志管理工具 - -```sh -mysqlbinlog [options] log-files1 log-files2 ... -``` - -* -d --database=name：指定数据库名称，只列出指定的数据库相关操作 - -* -o --offset=#：忽略掉日志中的前 n 行命令。 - -* -r --result-file=name：将输出的文本格式日志输出到指定文件。 - -* -s --short-form：显示简单格式，省略掉一些信息。 - -* --start-datatime=date1 --stop-datetime=date2：指定日期间隔内的所有日志 - -* --start-position=pos1 --stop-position=pos2：指定位置间隔内的所有日志 - - - -*** - - - -#### dump - -##### 命令介绍 - -mysqldump 客户端工具用来备份数据库或在不同数据库之间进行数据迁移，备份内容包含创建表，及插入表的 SQL 语句 - -```sh -mysqldump [options] db_name [tables] -mysqldump [options] --database/-B db1 [db2 db3...] -mysqldump [options] --all-databases/-A -``` - -连接选项： - -* -u --user=name：指定用户名 -* -p --password[=name]：指定密码 -* -h --host=name：指定服务器 IP 或域名 -* -P --port=#：指定连接端口 - -输出内容选项： - -* --add-drop-database：在每个数据库创建语句前加上 Drop database 语句 -* --add-drop-table：在每个表创建语句前加上 Drop table 语句 , 默认开启，不开启 (--skip-add-drop-table) -* -n --no-create-db：不包含数据库的创建语句 -* -t --no-create-info：不包含数据表的创建语句 -* -d --no-data：不包含数据 -* -T, --tab=name：自动生成两个文件：一个 .sql 文件，创建表结构的语句；一个 .txt 文件，数据文件，相当于 select into outfile - -示例： - -```sh -mysqldump -uroot -p2143 db01 tb_book --add-drop-database --add-drop-table > a -mysqldump -uroot -p2143 -T /tmp test city -``` - - - -*** - - - -##### 数据备份 - -命令行方式： - -* 备份命令：mysqldump -u root -p 数据库名称 > 文件保存路径 -* 恢复 - 1. 登录MySQL数据库：`mysql -u root p` - 2. 删除已经备份的数据库 - 3. 重新创建与备份数据库名称相同的数据库 - 4. 使用该数据库 - 5. 导入文件执行：`source 备份文件全路径` - -更多方式参考：https://time.geekbang.org/column/article/81925 - -图形化界面： - -* 备份 - - ![图形化界面备份](https://seazean.oss-cn-beijing.aliyuncs.com/img/DB/图形化界面备份.png) - -* 恢复 - - ![图形化界面恢复](https://seazean.oss-cn-beijing.aliyuncs.com/img/DB/图形化界面恢复.png) - - - - - -*** - - - -#### import - -mysqlimport 是客户端数据导入工具，用来导入mysqldump 加 -T 参数后导出的文本文件 - -```sh -mysqlimport [options] db_name textfile1 [textfile2...] -``` - -示例： - -```sh -mysqlimport -uroot -p2143 test /tmp/city.txt -``` - -导入 sql 文件，可以使用 MySQL 中的 source 指令 : - -```mysql -source 文件全路径 -``` - - - -*** - - - -#### show - -mysqlshow 客户端对象查找工具，用来很快地查找存在哪些数据库、数据库中的表、表中的列或者索引 - -```sh -mysqlshow [options] [db_name [table_name [col_name]]] -``` - -* --count：显示数据库及表的统计信息（数据库，表 均可以不指定） - -* -i：显示指定数据库或者指定表的状态信息 - -示例： - -```sh -#查询每个数据库的表的数量及表中记录的数量 -mysqlshow -uroot -p1234 --count -#查询test库中每个表中的字段书，及行数 -mysqlshow -uroot -p1234 test --count -#查询test库中book表的详细情况 -mysqlshow -uroot -p1234 test book --count -``` - - - *** @@ -440,13 +241,13 @@ SHOW PROCESSLIST：查看当前 MySQL 在进行的线程，可以实时地查看 | State | 显示使用当前连接的 sql 语句的状态，以查询为例，需要经过 copying to tmp table、sorting result、sending data等状态才可以完成 | | Info | 显示执行的 sql 语句，是判断问题语句的一个重要依据 | -**Sending data 状态**表示 MySQL 线程开始访问数据行并把结果返回给客户端，而不仅仅只是返回给客户端，是处于执行器过程中的任意阶段。由于在 Sending data 状态下，MySQL 线程需要做大量磁盘读取操作，所以是整个查询中耗时最长的状态。 +**Sending data 状态**表示 MySQL 线程开始访问数据行并把结果返回给客户端，而不仅仅只是返回给客户端，是处于执行器过程中的任意阶段。由于在 Sending data 状态下，MySQL 线程需要做大量磁盘读取操作，所以是整个查询中耗时最长的状态 -*** +*** @@ -463,7 +264,7 @@ SHOW PROCESSLIST：查看当前 MySQL 在进行的线程，可以实时地查看 1. 客户端发送一条查询给服务器 2. 服务器先会检查查询缓存，如果命中了缓存，则立即返回存储在缓存中的结果（一般是 K-V 键值对），否则进入下一阶段 3. 分析器进行 SQL 分析，再由优化器生成对应的执行计划 -4. MySQL 根据优化器生成的执行计划，调用存储引擎的 API 来执行查询 +4. 执行器根据优化器生成的执行计划，调用存储引擎的 API 来执行查询 5. 将结果返回给客户端 大多数情况下不建议使用查询缓存，因为查询缓存往往弊大于利 @@ -479,7 +280,7 @@ SHOW PROCESSLIST：查看当前 MySQL 在进行的线程，可以实时地查看 ##### 缓存配置 -1. 查看当前的 MySQL 数据库是否支持查询缓存： +1. 查看当前 MySQL 数据库是否支持查询缓存： ```mysql SHOW VARIABLES LIKE 'have_query_cache'; -- YES @@ -598,7 +399,7 @@ SELECT * FROM t WHERE id = 1; 解析器：处理语法和解析查询，生成一课对应的解析树 * 先做**词法分析**，输入的是由多个字符串和空格组成的一条 SQL 语句，MySQL 需要识别出里面的字符串分别是什么代表什么。从输入的 select 这个关键字识别出来这是一个查询语句；把字符串 t 识别成 表名 t，把字符串 id 识别成列 id -* 然后做**语法分析**，根据词法分析的结果，语法分析器会根据语法规则，判断你输入的这个 SQL 语句是否满足 MySQL 语法。如果你的语句不对，就会收到 `You have an error in your SQL syntax` 的错误提醒 +* 然后做**语法分析**，根据词法分析的结果，语法分析器会根据语法规则，判断你输入的这个 SQL 语句是否满足 MySQL 语法。如果语句不对，就会收到 `You have an error in your SQL syntax` 的错误提醒 预处理器：进一步检查解析树的合法性，比如数据表和数据列是否存在、别名是否有歧义等 @@ -633,7 +434,7 @@ MySQL 中保存着两种统计数据： * innodb_table_stats 存储了表的统计数据，每一条记录对应着一个表的统计数据 * innodb_index_stats 存储了索引的统计数据，每一条记录对应着一个索引的一个统计项的数据 -MySQL 在真正执行语句之前，并不能精确地知道满足条件的记录有多少条，只能根据统计信息来估算记录，统计信息就是索引的区分度,一个索引上不同的值的个数（比如性别只能是男女，就是 2 ），称之为基数（cardinality），**基数越大说明区分度越好** +MySQL 在真正执行语句之前，并不能精确地知道满足条件的记录有多少条，只能根据统计信息来估算记录，统计信息就是索引的区分度，一个索引上不同的值的个数（比如性别只能是男女，就是 2 ），称之为基数（cardinality），**基数越大说明区分度越好** 通过**采样统计**来获取基数，InnoDB 默认会选择 N 个数据页，统计这些页面上的不同值得到一个平均值，然后乘以这个索引的页面数，就得到了这个索引的基数 @@ -762,49 +563,48 @@ KILL CONNECTION id -**** - - +*** -## 单表操作 +### 常用工具 -### SQL +#### mysql -- SQL +mysql 不是指 mysql 服务，而是指 mysql 的客户端工具 - - Structured Query Language：结构化查询语言 - - 定义了操作所有关系型数据库的规则，每种数据库操作的方式可能会存在不一样的地方，称为“方言” +```sh +mysql [options] [database] +``` -- SQL 通用语法 +* -u --user=name：指定用户名 +* -p --password[=name]：指定密码 +* -h --host=name：指定服务器IP或域名 +* -P --port=#：指定连接端口 +* -e --execute=name：执行SQL语句并退出，在控制台执行SQL语句，而不用连接到数据库执行 - - SQL 语句可以单行或多行书写，以**分号结尾**。 - - 可使用空格和缩进来增强语句的可读性。 - - MySQL 数据库的 SQL 语句不区分大小写，**关键字建议使用大写**。 - - 数据库的注释： - - 单行注释：-- 注释内容 #注释内容（MySQL 特有） - - 多行注释：/* 注释内容 */ +示例： -- SQL 分类 +```sh +mysql -h 127.0.0.1 -P 3306 -u root -p +mysql -uroot -p2143 db01 -e "select * from tb_book"; +``` - - DDL（Data Definition Language）数据定义语言 - - 用来定义数据库对象：数据库，表，列等。关键字：create、drop,、alter 等 - - DML（Data Manipulation Language）数据操作语言 +*** - - 用来对数据库中表的数据进行增删改。关键字：insert、delete、update 等 - - DQL（Data Query Language）数据查询语言 - - 用来查询数据库中表的记录(数据)。关键字：select、where 等 +#### admin - - DCL（Data Control Language）数据控制语言 +mysqladmin 是一个执行管理操作的客户端程序，用来检查服务器的配置和当前状态、创建并删除数据库等 - - 用来定义数据库的访问权限和安全级别，及创建用户。关键字：grant， revoke等 +通过 `mysqladmin --help` 指令查看帮助文档 - ![](https://seazean.oss-cn-beijing.aliyuncs.com/img/DB/MySQL-SQL分类.png) +```sh +mysqladmin -uroot -p2143 create 'test01'; +``` @@ -812,11 +612,215 @@ KILL CONNECTION id -### DDL - -#### 数据库 +#### binlog -* R(Retrieve)：查询 +服务器生成的日志文件以二进制格式保存，如果需要检查这些文本，就要使用 mysqlbinlog 日志管理工具 + +```sh +mysqlbinlog [options] log-files1 log-files2 ... +``` + +* -d --database=name：指定数据库名称，只列出指定的数据库相关操作 + +* -o --offset=#：忽略掉日志中的前 n 行命令。 + +* -r --result-file=name：将输出的文本格式日志输出到指定文件。 + +* -s --short-form：显示简单格式，省略掉一些信息。 + +* --start-datatime=date1 --stop-datetime=date2：指定日期间隔内的所有日志 + +* --start-position=pos1 --stop-position=pos2：指定位置间隔内的所有日志 + + + +*** + + + +#### dump + +##### 命令介绍 + +mysqldump 客户端工具用来备份数据库或在不同数据库之间进行数据迁移，备份内容包含创建表，及插入表的 SQL 语句 + +```sh +mysqldump [options] db_name [tables] +mysqldump [options] --database/-B db1 [db2 db3...] +mysqldump [options] --all-databases/-A +``` + +连接选项： + +* -u --user=name：指定用户名 +* -p --password[=name]：指定密码 +* -h --host=name：指定服务器 IP 或域名 +* -P --port=#：指定连接端口 + +输出内容选项： + +* --add-drop-database：在每个数据库创建语句前加上 Drop database 语句 +* --add-drop-table：在每个表创建语句前加上 Drop table 语句 , 默认开启，不开启 (--skip-add-drop-table) +* -n --no-create-db：不包含数据库的创建语句 +* -t --no-create-info：不包含数据表的创建语句 +* -d --no-data：不包含数据 +* -T, --tab=name：自动生成两个文件：一个 .sql 文件，创建表结构的语句；一个 .txt 文件，数据文件，相当于 select into outfile + +示例： + +```sh +mysqldump -uroot -p2143 db01 tb_book --add-drop-database --add-drop-table > a +mysqldump -uroot -p2143 -T /tmp test city +``` + + + +*** + + + +##### 数据备份 + +命令行方式： + +* 备份命令：mysqldump -u root -p 数据库名称 > 文件保存路径 +* 恢复 + 1. 登录MySQL数据库：`mysql -u root p` + 2. 删除已经备份的数据库 + 3. 重新创建与备份数据库名称相同的数据库 + 4. 使用该数据库 + 5. 导入文件执行：`source 备份文件全路径` + +更多方式参考：https://time.geekbang.org/column/article/81925 + +图形化界面： + +* 备份 + + ![图形化界面备份](https://seazean.oss-cn-beijing.aliyuncs.com/img/DB/图形化界面备份.png) + +* 恢复 + + ![图形化界面恢复](https://seazean.oss-cn-beijing.aliyuncs.com/img/DB/图形化界面恢复.png) + + + + + +*** + + + +#### import + +mysqlimport 是客户端数据导入工具，用来导入mysqldump 加 -T 参数后导出的文本文件 + +```sh +mysqlimport [options] db_name textfile1 [textfile2...] +``` + +示例： + +```sh +mysqlimport -uroot -p2143 test /tmp/city.txt +``` + +导入 sql 文件，可以使用 MySQL 中的 source 指令 : + +```mysql +source 文件全路径 +``` + + + +*** + + + +#### show + +mysqlshow 客户端对象查找工具，用来很快地查找存在哪些数据库、数据库中的表、表中的列或者索引 + +```sh +mysqlshow [options] [db_name [table_name [col_name]]] +``` + +* --count：显示数据库及表的统计信息（数据库，表 均可以不指定） + +* -i：显示指定数据库或者指定表的状态信息 + +示例： + +```sh +#查询每个数据库的表的数量及表中记录的数量 +mysqlshow -uroot -p1234 --count +#查询test库中每个表中的字段书，及行数 +mysqlshow -uroot -p1234 test --count +#查询test库中book表的详细情况 +mysqlshow -uroot -p1234 test book --count +``` + + + + + + + +**** + + + + + +## 单表操作 + +### SQL + +- SQL + + - Structured Query Language：结构化查询语言 + - 定义了操作所有关系型数据库的规则，每种数据库操作的方式可能会存在不一样的地方，称为“方言” + +- SQL 通用语法 + + - SQL 语句可以单行或多行书写，以**分号结尾**。 + - 可使用空格和缩进来增强语句的可读性。 + - MySQL 数据库的 SQL 语句不区分大小写，**关键字建议使用大写**。 + - 数据库的注释： + - 单行注释：-- 注释内容 #注释内容（MySQL 特有） + - 多行注释：/* 注释内容 */ + +- SQL 分类 + + - DDL（Data Definition Language）数据定义语言 + + - 用来定义数据库对象：数据库，表，列等。关键字：create、drop,、alter 等 + + - DML（Data Manipulation Language）数据操作语言 + + - 用来对数据库中表的数据进行增删改。关键字：insert、delete、update 等 + + - DQL（Data Query Language）数据查询语言 + + - 用来查询数据库中表的记录(数据)。关键字：select、where 等 + + - DCL（Data Control Language）数据控制语言 + + - 用来定义数据库的访问权限和安全级别，及创建用户。关键字：grant， revoke等 + + ![](https://seazean.oss-cn-beijing.aliyuncs.com/img/DB/MySQL-SQL分类.png) + + + +*** + + + +### DDL + +#### 数据库 + +* R(Retrieve)：查询 * 查询所有数据库： @@ -1646,7 +1650,7 @@ SELECT * FROM emp WHERE name REGEXP '[uvw]';-- 匹配包含 uvw 的name值 #### 约束介绍 -约束：对表中的数据进行限定，保证数据的正确性、有效性、完整性！ +约束：对表中的数据进行限定，保证数据的正确性、有效性、完整性 约束的分类： @@ -1720,7 +1724,7 @@ SELECT * FROM emp WHERE name REGEXP '[uvw]';-- 匹配包含 uvw 的name值 #### 主键自增 -主键自增约束可以为空，并自动增长。删除某条数据不影响自增的下一个数值，依然按照前一个值自增。 +主键自增约束可以为空，并自动增长。删除某条数据不影响自增的下一个数值，依然按照前一个值自增 * 建表时添加主键自增约束 @@ -2118,19 +2122,11 @@ STRAIGHT_JOIN与 JOIN 类似，只不过左表始终在右表之前读取，只 salary DOUBLE -- 员工工资 ); -- 添加数据 - INSERT INTO employee VALUES (1001,'孙悟空',1005,9000.00), - (1002,'猪八戒',1005,8000.00), - (1003,'沙和尚',1005,8500.00), - (1004,'小白龙',1005,7900.00), - (1005,'唐僧',NULL,15000.00), - (1006,'武松',1009,7600.00), - (1007,'李逵',1009,7400.00), - (1008,'林冲',1009,8100.00), - (1009,'宋江',NULL,16000.00); + INSERT INTO employee VALUES (1001,'孙悟空',1005,9000.00),..,(1009,'宋江',NULL,16000.00); ``` - + ![](https://seazean.oss-cn-beijing.aliyuncs.com/img/DB/自关联查询数据准备.png) - + * 数据查询 ```mysql @@ -2330,7 +2326,7 @@ BNL 即 Block Nested-Loop Join 算法，由于要访问多次被驱动表，会 子查询物化会产生建立临时表的成本，但是将子查询转化为连接查询可以充分发挥优化器的作用，所以引入：半连接 -* t1 和 t2 表进行半连接，对于 t1 表中的某条记录，只需要关心在 s2 表中是否存在，而不需要关心有多少条记录与之匹配，最终结果集只保留 t1 的记录 +* t1 和 t2 表进行半连接，对于 t1 表中的某条记录，只需要关心在 t2 表中是否存在，而不需要关心有多少条记录与之匹配，最终结果集只保留 t1 的记录 * 半连接只是执行子查询的一种方式，MySQL 并没有提供面向用户的半连接语法 @@ -3581,7 +3577,7 @@ MySQL 支持的存储引擎： MyISAM 存储引擎： * 特点：不支持事务和外键，读取速度快，节约资源 -* 应用场景：查询和插入操作为主，只有很少更新和删除操作，并对事务的完整性、并发性要求不高 +* 应用场景：**适用于读多写少的场景**，对事务的完整性要求不高，比如一些数仓、离线数据、支付宝的年度总结之类的场景，业务进行只读操作，查询起来会更快 * 存储方式： * 每个 MyISAM 在磁盘上存储成 3 个文件，其文件名都和表名相同，拓展名不同 * 表的定义保存在 .frm 文件，表数据保存在 .MYD (MYData) 文件中，索引保存在 .MYI (MYIndex) 文件中 @@ -3597,7 +3593,7 @@ InnoDB 存储引擎：(MySQL5.5 版本后默认的存储引擎) MEMORY 存储引擎： - 特点：每个 MEMORY 表实际对应一个磁盘文件 ，该文件中只存储表的结构，表数据保存在内存中，且默认**使用 HASH 索引**，所以数据默认就是无序的，但是在需要快速定位记录可以提供更快的访问，**服务一旦关闭，表中的数据就会丢失**，存储不安全 -- 应用场景：通常用于更新不太频繁的小表，用以快速得到访问结果，类似缓存 +- 应用场景：**缓存型存储引擎**，通常用于更新不太频繁的小表，用以快速得到访问结果 - 存储方式：表结构保存在 .frm 中 MERGE 存储引擎： @@ -3646,14 +3642,10 @@ MERGE 存储引擎： | 批量插入速度 | 高 | 低 | 高 | | **外键** | **不支持** | **支持** | **不支持** | -MyISAM 和 InnoDB 的区别？ +只读场景 MyISAM 比 InnoDB 更快： -* 事务：InnoDB 支持事务，MyISAM 不支持事务 -* 外键：InnoDB 支持外键，MyISAM 不支持外键 -* 索引：InnoDB 是聚集（聚簇）索引，MyISAM 是非聚集（非聚簇）索引 - -* 锁粒度：InnoDB 最小的锁粒度是行锁，MyISAM 最小的锁粒度是表锁 -* 存储结构：参考本节上半部分 +* 底层存储结构有差别，MyISAM 是非聚簇索引，叶子节点保存的是数据的具体地址，不用回表查询 +* InnoDB 每次查询需要维护 MVCC 版本状态，保证并发状态下的读写冲突问题 @@ -3716,7 +3708,7 @@ MyISAM 和 InnoDB 的区别？ #### 基本介绍 -MySQL 官方对索引的定义为：索引（index）是帮助 MySQL 高效获取数据的一种数据结构，**本质是排好序的快速查找数据结构。**在表数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式指向数据， 这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引。 +MySQL 官方对索引的定义为：索引（index）是帮助 MySQL 高效获取数据的一种数据结构，**本质是排好序的快速查找数据结构。**在表数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式指向数据， 这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引 **索引是在存储引擎层实现的**，所以并没有统一的索引标准，即不同存储引擎的索引的工作方式并不一样 @@ -3768,7 +3760,7 @@ MySQL 官方对索引的定义为：索引（index）是帮助 MySQL 高效获 | R-tree | 不支持 | 支持 | 不支持 | | Full-text | 5.6 版本之后支持 | 支持 | 不支持 | -联合索引图示：根据身高年龄建立的组合索引（height,age） +联合索引图示：根据身高年龄建立的组合索引（height、age） ![](https://seazean.oss-cn-beijing.aliyuncs.com/img/DB/MySQL-组合索引图.png) @@ -3995,6 +3987,8 @@ InnoDB 存储引擎中有页（Page）的概念，页是 MySQL 磁盘管理的 * InnoDB 引擎将若干个地址连接磁盘块，以此来达到页的大小 16KB * 在查询数据时如果一个页中的每条数据都能有助于定位数据记录的位置，这将会减少磁盘 I/O 次数，提高查询效率 +超过 16KB 的一条记录，主键索引页只会存储部分数据和指向**溢出页**的指针，剩余数据都会分散存储在溢出页中 + 数据页物理结构，从上到下： * File Header：上一页和下一页的指针、该页的类型（索引页、数据页、日志页等）、**校验和**、LSN（最近一次修改当前页面时的系统 lsn 值，事务持久性部分详解）等信息 @@ -4143,10 +4137,12 @@ B+ 树为了保持索引的有序性，在插入新值的时候需要做相应 一般选用数据小的字段做索引，字段长度越小，普通索引的叶子节点就越小，普通索引占用的空间也就越小 -自增主键的插入数据模式，可以让主键索引尽量地保持递增顺序插入，不涉及到挪动其他记录，**避免了页分裂** +自增主键的插入数据模式，可以让主键索引尽量地保持递增顺序插入，不涉及到挪动其他记录，**避免了页分裂**，页分裂的目的就是保证后一个数据页中的所有行主键值比前一个数据页中主键值大 +参考文章：https://developer.aliyun.com/article/919861 + *** @@ -4252,7 +4248,7 @@ B+ 树为了保持索引的有序性，在插入新值的时候需要做相应 * 需要存储引擎将索引中的数据与条件进行判断（所以**条件列必须都在同一个索引中**），所以优化是基于存储引擎的，只有特定引擎可以使用，适用于 InnoDB 和 MyISAM * 存储引擎没有调用跨存储引擎的能力，跨存储引擎的功能有存储过程、触发器、视图，所以调用这些功能的不可以进行索引下推优化 -* 对于 InnoDB 引擎只适用于二级索引，InnoDB 的聚簇索引会将整行数据读到缓冲区，不再需要去回表查询了，索引下推的目的减少回表的 IO 次数也就失去了意义 +* 对于 InnoDB 引擎只适用于二级索引，InnoDB 的聚簇索引会将整行数据读到缓冲区，不再需要去回表查询了 工作过程：用户表 user，(name, age) 是联合索引 @@ -4430,8 +4426,8 @@ INSERT INTO t VALUES('2017-4-1',1),('2018-4-1',1);-- 这两行记录分别落在 分区表的特点： -* 一个是第一次访问的时候需要访问所有分区 -* 在 Server 层认为这是同一张表，因此所有分区共用同一个 MDL 锁 +* 第一次访问的时候需要访问所有分区 +* 在 Server 层认为这是同一张表，因此**所有分区共用同一个 MDL 锁** * 在引擎层认为这是不同的表，因此 MDL 锁之后的执行过程，会根据分区表规则，只访问需要的分区 @@ -4444,14 +4440,14 @@ INSERT INTO t VALUES('2017-4-1',1),('2018-4-1',1);-- 这两行记录分别落在 分区表的优点： -* 对业务透明，相对于用户分表来说，使用分区表的业务代码更简洁。 +* 对业务透明，相对于用户分表来说，使用分区表的业务代码更简洁 * 分区表可以很方便的清理历史数据。按照时间分区的分区表，就可以直接通过 `alter table t drop partition` 这个语法直接删除分区文件，从而删掉过期的历史数据，与使用 drop 语句删除数据相比，优势是速度快、对系统影响小 使用分区表，不建议创建太多的分区，注意事项： * 分区并不是越细越好，单表或者单分区的数据一千万行，只要没有特别大的索引，对于现在的硬件能力来说都已经是小表 -* 分区不要提前预留太多，在使用之前预先创建即可。比如是按月分区，每年年底时再把下一年度的 12 个新分区创建上即可，并且对于没有数据的历史分区，要及时的 drop 掉。 +* 分区不要提前预留太多，在使用之前预先创建即可。比如是按月分区，每年年底时再把下一年度的 12 个新分区创建上即可，并且对于没有数据的历史分区，要及时的 drop 掉 @@ -4583,8 +4579,6 @@ select v from ht where k >= M order by t_modified desc limit 100; #### 执行频率 -随着生产数据量的急剧增长，很多 SQL 语句逐渐显露出性能问题，对生产的影响也越来越大，此时有问题的 SQL 语句就成为整个系统性能的瓶颈，因此必须要进行优化 - MySQL 客户端连接成功后，查询服务器状态信息： ```mysql @@ -4716,12 +4710,10 @@ EXPLAIN SELECT * FROM table_1 WHERE id = 1; MySQL **执行计划的局限**： * 只是计划，不是执行 SQL 语句，可以随着底层优化器输入的更改而更改 -* EXPLAIN 不会告诉显示关于触发器、存储过程的信息对查询的影响情况 -* EXPLAIN 不考虑各种 Cache +* EXPLAIN 不会告诉显示关于触发器、存储过程的信息对查询的影响情况， 不考虑各种 Cache * EXPLAIN 不能显示 MySQL 在执行查询时的动态，因为执行计划在执行**查询之前生成** -* EXPALIN 部分统计信息是估算的，并非精确值 * EXPALIN 只能解释 SELECT 操作，其他操作要重写为 SELECT 后查看执行计划 -* EXPLAIN PLAN 显示的是在解释语句时数据库将如何运行 SQL 语句，由于执行环境和 EXPLAIN PLAN 环境的不同，此计划可能与 SQL 语句**实际的执行计划不同** +* EXPLAIN PLAN 显示的是在解释语句时数据库将如何运行 SQL 语句，由于执行环境和 EXPLAIN PLAN 环境的不同，此计划可能与 SQL 语句**实际的执行计划不同**，部分统计信息是估算的，并非精确值 SHOW WARINGS：在使用 EXPALIN 命令后执行该语句，可以查询与执行计划相关的拓展信息，展示出 Level、Code、Message 三个字段，当 Code 为 1003 时，Message 字段展示的信息类似于将查询语句重写后的信息，但是不是等价，不能执行复制过来运行 @@ -4861,7 +4853,7 @@ key_len： * Using where：搜索的数据需要在 Server 层判断，无法使用索引下推 * Using join buffer：连接查询被驱动表无法利用索引，需要连接缓冲区来存储中间结果 * Using filesort：无法利用索引完成排序（优化方向），需要对数据使用外部排序算法，将取得的数据在内存或磁盘中进行排序 -* Using temporary：表示 MySQL 需要使用临时表来存储结果集，常见于排序、去重、分组等场景 +* Using temporary：表示 MySQL 需要使用临时表来存储结果集，常见于**排序、去重（UNION）、分组**等场景 * Select tables optimized away：说明仅通过使用索引，优化器可能仅从聚合函数结果中返回一行 * No tables used：Query 语句中使用 from dual 或不含任何 from 子句 @@ -5045,7 +5037,7 @@ CREATE INDEX idx_seller_name_sta_addr ON tb_seller(name, status, address); # 联 * **字符串不加单引号**，造成索引失效：隐式类型转换，当字符串和数字比较时会**把字符串转化为数字** - 在查询时，没有对字符串加单引号，查询优化器会调用 CAST 函数将 status 转换为 int 进行比较，造成索引失效 + 没有对字符串加单引号，查询优化器会调用 CAST 函数将 status 转换为 int 进行比较，造成索引失效 ```mysql EXPLAIN SELECT * FROM tb_seller WHERE name='小米科技' AND status = 1; @@ -5138,7 +5130,7 @@ CREATE INDEX idx_seller_name_sta_addr ON tb_seller(name, status, address); # 联 EXPLAIN SELECT * FROM tb_seller WHERE sellerId NOT IN ('alibaba','huawei'); ``` -* [MySQL 实战 45 讲](https://time.geekbang.org/column/article/74687)该章节最后提出了一种场景，获取到数据以后 Server 层还会做判断 +* [MySQL 实战 45 讲](https://time.geekbang.org/column/article/74687)该章节最后提出了一种慢查询场景，获取到数据以后 Server 层还会做判断 @@ -5206,7 +5198,7 @@ SHOW GLOBAL STATUS LIKE 'Handler_read%'; ##### 自增机制 -自增主键可以让主键索引尽量地保持递增顺序插入，避免了页分裂，因此索引更紧凑 +自增主键可以让主键索引尽量地保持在数据页中递增顺序插入，不自增需要寻找其他页插入，导致随机 IO 和页分裂的情况 表的结构定义存放在后缀名为.frm 的文件中，但是并不会保存自增值，不同的引擎对于自增值的保存策略不同： @@ -5248,7 +5240,7 @@ MySQL 不同的自增 id 在达到上限后的表现不同： ```c++ do { - new_id = thread_id_counter++; + new_id = thread_id_counter++; } while (!thread_ids.insert_unique(new_id).second); ``` @@ -5392,7 +5384,7 @@ CREATE TABLE `emp` ( PRIMARY KEY (`id`) ) ENGINE=INNODB DEFAULT CHARSET=utf8mb4; INSERT INTO `emp` (`id`, `name`, `age`, `salary`) VALUES('1','Tom','25','2300');-- ... -CREATE INDEX idx_emp_age_salary ON emp(age,salary); +CREATE INDEX idx_emp_age_salary ON emp(age, salary); ``` * 第一种是通过对返回数据进行排序，所有不通过索引直接返回结果的排序都叫 FileSort 排序，会在内存中重新排序 @@ -5429,7 +5421,7 @@ CREATE INDEX idx_emp_age_salary ON emp(age,salary); 内存临时表，MySQL 有两种 Filesort 排序算法： -* rowid 排序：首先根据条件（回表）取出排序字段和信息，然后在**排序区 sort buffer（Server 层）**中排序，如果 sort buffer 不够，则在临时表 temporary table 中存储排序结果。完成排序后再根据行指针**回表读取记录**，该操作可能会导致大量随机 I/O 操作 +* rowid 排序：首先根据条件取出排序字段和信息，然后在**排序区 sort buffer（Server 层）**中排序，如果 sort buffer 不够，则在临时表 temporary table 中存储排序结果。完成排序后再根据行指针**回表读取记录**，该操作可能会导致大量随机 I/O 操作 说明：对于临时内存表，回表过程只是简单地根据数据行的位置，直接访问内存得到数据，不会导致多访问磁盘，优先选择该方式 @@ -5482,7 +5474,7 @@ GROUP BY 也会进行排序操作，与 ORDER BY 相比，GROUP BY 主要只是 * 创建索引：索引本身有序，不需要临时表，也不需要再额外排序 ```mysql - CREATE INDEX idx_emp_age_salary ON emp(age,salary); + CREATE INDEX idx_emp_age_salary ON emp(age, salary); ``` ![](https://seazean.oss-cn-beijing.aliyuncs.com/img/DB/MySQL-优化SQL GROUP BY排序3.png) @@ -5558,7 +5550,7 @@ MySQL 4.1 版本之后，开始支持 SQL 的子查询 ![](https://seazean.oss-cn-beijing.aliyuncs.com/img/DB/MySQL-优化SQL嵌套查询2.png) - 连接查询之所以效率更高 ，是因为不需要在内存中创建临时表来完成逻辑上需要两个步骤的查询工作 + 连接查询之所以效率更高 ，是因为**不需要在内存中创建临时表**来完成逻辑上需要两个步骤的查询工作 @@ -5593,7 +5585,7 @@ MySQL 4.1 版本之后，开始支持 SQL 的子查询 * 优化方式二：方案适用于主键自增的表，可以把 LIMIT 查询转换成某个位置的查询 ```mysql - EXPLAIN SELECT * FROM tb_user_1 WHERE id > 200000 LIMIT 10; -- 写法 1 + EXPLAIN SELECT * FROM tb_user_1 WHERE id > 200000 LIMIT 10; -- 写法 1 EXPLAIN SELECT * FROM tb_user_1 WHERE id BETWEEN 200000 and 200010; -- 写法 2 ``` @@ -5757,7 +5749,7 @@ Flush 链表是一个用来**存储脏页**的链表，对于已经修改过的 * 从 Flush 链表中刷新一部分页面到磁盘： * **后台线程定时**从 Flush 链表刷脏，根据系统的繁忙程度来决定刷新速率，这种方式称为 BUF_FLUSH_LIST - * 线程刷脏的比较慢，导致用户线程加载一个新的数据页时发现没有空闲缓冲页，此时会尝试从 LRU 链表尾部寻找未修改的缓冲页直接释放，如果没有就将 LRU 链表尾部的一个脏页**同步刷新**到磁盘，速度较慢，这种方式称为 BUF_FLUSH_SINGLE_PAGE + * 线程刷脏的比较慢，导致用户线程加载一个新的数据页时发现没有空闲缓冲页，此时会尝试从 LRU 链表尾部寻找缓冲页直接释放，如果该页面是已经修改过的脏页就**同步刷新**到磁盘，速度较慢，这种方式称为 BUF_FLUSH_SINGLE_PAGE * 从 LRU 链表的冷数据中刷新一部分页面到磁盘，即：BUF_FLUSH_LRU * 后台线程会定时从 LRU 链表的尾部开始扫描一些页面，扫描的页面数量可以通过系统变量 `innodb_lru_scan_depth` 指定，如果在 LRU 链表中发现脏页，则把它们刷新到磁盘，这种方式称为 BUF_FLUSH_LRU * 控制块里会存储该缓冲页是否被修改的信息，所以可以很容易的获取到某个缓冲页是否是脏页 @@ -5774,9 +5766,9 @@ Flush 链表是一个用来**存储脏页**的链表，对于已经修改过的 ##### LRU 链表 -当 Buffer Pool 中没有空闲缓冲页时就需要淘汰掉最近最少使用的部分缓冲页，为了实现这个功能，MySQL 创建了一个 LRU 链表，当访问某个页时： +Buffer Pool 需要保证缓存的命中率，所以 MySQL 创建了一个 LRU 链表，当访问某个页时： -* 如果该页不在 Buffer Pool 中，把该页从磁盘加载进来后会将该缓冲页对应的控制块作为节点放入 **LRU 链表的头部** +* 如果该页不在 Buffer Pool 中，把该页从磁盘加载进来后会将该缓冲页对应的控制块作为节点放入 **LRU 链表的头部**，保证热点数据在链表头 * 如果该页在 Buffer Pool 中，则直接把该页对应的控制块移动到 LRU 链表的头部，所以 LRU 链表尾部就是最近最少使用的缓冲页 MySQL 基于局部性原理提供了预读功能： @@ -5784,7 +5776,7 @@ MySQL 基于局部性原理提供了预读功能： * 线性预读：系统变量 `innodb_read_ahead_threshold`，如果顺序访问某个区（extent：16 KB 的页，连续 64 个形成一个区，一个区默认 1MB 大小）的页面数超过了该系统变量值，就会触发一次**异步读取**下一个区中全部的页面到 Buffer Pool 中 * 随机预读：如果某个区 13 个连续的页面都被加载到 Buffer Pool，无论这些页面是否是顺序读取，都会触发一次**异步读取**本区所有的其他页面到 Buffer Pool 中 -预读会造成加载太多用不到的数据页，造成那些使用**频率很高的数据页被挤到 LRU 链表尾部**，所以 InnoDB 将 LRU 链表分成两段： +预读会造成加载太多用不到的数据页，造成那些使用频率很高的数据页被挤到 LRU 链表尾部，所以 InnoDB 将 LRU 链表分成两段，**冷热数据隔离**： * 一部分存储使用频率很高的数据页，这部分链表也叫热数据，young 区，靠近链表头部的区域 * 一部分存储使用频率不高的冷数据，old 区，靠近链表尾部，默认占 37%，可以通过系统变量 `innodb_old_blocks_pct` 指定 @@ -5851,7 +5843,7 @@ MySQL 5.7.5 之前 `innodb_buffer_pool_size` 只支持在系统启动时修改 #### Change -InnoDB 管理的 Buffer Pool 中有一块内存叫 Change Buffer 用来对**增删改操作**提供缓存，参数 `innodb_change_buffer_max_size ` 来动态设置，设置为 50 时表示 Change Buffer 的大小最多只能占用 Buffer Pool 的 50% +InnoDB 管理的 Buffer Pool 中有一块内存叫 Change Buffer 用来对**增删改操作**提供缓存，可以通过参数来动态设置，设置为 50 时表示 Change Buffer 的大小最多占用 Buffer Pool 的 50% * 唯一索引的更新不能使用 Change Buffer，需要将数据页读入内存，判断没有冲突在写入 * 普通索引可以使用 Change Buffer，**直接写入 Buffer 就结束**，不用校验唯一性 @@ -5908,7 +5900,7 @@ SHOW PROCESSLIST 获取线程信息后，处于 Sending to client 状态代表 read_rnd_buffer 是 MySQL 的随机读缓冲区，当按任意顺序读取记录行时将分配一个随机读取缓冲区，进行排序查询时，MySQL 会首先扫描一遍该缓冲，以避免磁盘搜索，提高查询速度，大小是由 read_rnd_buffer_size 参数控制的 -**Multi-Range Read 优化**，将随机 IO 转化为顺序 IO 以降低查询过程中 IO 开销，因为大多数的数据都是按照主键递增顺序插入得到，所以按照主键的递增顺序查询的话，对磁盘的读比较接近顺序读，能够提升读性能 +Multi-Range Read 优化，**将随机 IO 转化为顺序 IO** 以降低查询过程中 IO 开销，因为大多数的数据都是按照主键递增顺序插入得到，所以按照主键的递增顺序查询的话，对磁盘的读比较接近顺序读，能够提升读性能 二级索引为 a，聚簇索引为 id，优化回表流程： @@ -6320,7 +6312,7 @@ InnoDB 存储引擎支持事务，所以加锁分析是基于该存储引擎 * Read Committed 级别，增删改操作会加写锁（行锁），读操作不加锁 - 在 Server 层过滤条件时发现不满足的记录会调用 unlock_row 方法释放该记录的行锁，保证最后只有满足条件的记录加锁，但是扫表过程中每条记录的**加锁操作不能省略**。所以对数据量很大的表做批量修改时，如果无法使用相应的索引（全表扫描），在Server 过滤数据时就会特别慢，出现虽然没有修改某些行的数据，但是还是被锁住了的现象（锁表），这种情况同样适用于 RR + 在 Server 层过滤条件时发现不满足的记录会调用 unlock_row 方法释放该记录的行锁，保证最后只有满足条件的记录加锁，但是扫表过程中每条记录的**加锁操作不能省略**。所以对数据量很大的表做批量修改时，如果无法使用相应的索引（全表扫描），在 Server 过滤数据时就会特别慢，出现虽然没有修改某些行的数据，但是还是被锁住了的现象（锁表），这种情况同样适用于 RR * Repeatable Read 级别，增删改操作会加写锁，读操作不加锁。因为读写锁不兼容，**加了读锁后其他事务就无法修改数据**，影响了并发性能，为了保证隔离性和并发性，MySQL 通过 MVCC 解决了读写冲突。RR 级别下的锁有很多种，锁机制章节详解 @@ -6350,7 +6342,7 @@ InnoDB 存储引擎提供了两种事务日志：redo log（重做日志）和 u * redo log 用于保证事务持久性 * undo log 用于保证事务原子性和隔离性 -undo log 属于逻辑日志，根据每行操作进行记录，记录了 SQL 执行相关的信息，用来回滚行记录到某个版本 +undo log 属于**逻辑日志**，根据每行操作进行记录，记录了 SQL 执行相关的信息，用来回滚行记录到某个版本 当事务对数据库进行修改时，InnoDB 会先记录对应的 undo log，如果事务执行失败或调用了 rollback 导致事务回滚，InnoDB 会根据 undo log 的内容**做与之前相反的操作**： @@ -6434,9 +6426,9 @@ roll_pointer 是一个指针，**指向记录对应的 undo log 日志**，一 * 将旧纪录进行 delete mark，在更新语句提交后由 purge 线程移入垃圾链表 * 根据更新的各列的值创建一条新纪录，插入到聚簇索引中 -在对一条记录修改前会**将记录的隐藏列 trx_id 和 roll_pointer 的旧值记录到 undo log 对应的属性中**，这样当前记录的 roll_pointer 指向当前 undo log 记录，当前 undo log 记录的 roll_pointer 指向旧的 undo log 记录，**形成一个版本链** +在对一条记录修改前会**将记录的隐藏列 trx_id 和 roll_pointer 的旧值记录到当前 undo log 对应的属性中**，这样当前记录的 roll_pointer 指向当前 undo log 记录，当前 undo log 记录的 roll_pointer 指向旧的 undo log 记录，**形成一个版本链** -UPDATE、DELETE 操作产生的 undo 日志可能会用于其他事务的 MVCC 操作，所以不能立即删除 +UPDATE、DELETE 操作产生的 undo 日志会用于其他事务的 MVCC 操作，所以不能立即删除，INSERT 可以删除的原因是 MVCC 是对现有数据的快照 @@ -6557,7 +6549,7 @@ undo log 是逻辑日志，记录的是每个事务对数据执行的操作， undo log 的作用： * 保证事务进行 rollback 时的原子性和一致性，当事务进行回滚的时候可以用 undo log 的数据进行恢复 -* 用于 MVCC 快照读，通过读取 undo log 的历史版本数据可以实现不同事务版本号都拥有自己独立的快照数据版本 +* 用于 MVCC 快照读，通过读取 undo log 的历史版本数据可以实现不同事务版本号都拥有自己独立的快照数据 undo log 主要分为两种： @@ -6603,7 +6595,7 @@ Read View 几个属性： creator 创建一个 Read View，进行可见性算法分析：（解决了读未提交） * db_trx_id == creator_trx_id：表示这个数据就是当前事务自己生成的，自己生成的数据自己肯定能看见，所以此数据对 creator 是可见的 -* db_trx_id < min_trx_id：该版本对应的事务 ID 小于 Read view 中的最小活跃事务 ID，则这个事务在当前事务之前就已经被提交了，对 creator 可见（因为比已提交的最大事务 ID 小的并不一定已经提交，所以应该先判断是否在活跃事务列表） +* db_trx_id < min_trx_id：该版本对应的事务 ID 小于 Read view 中的最小活跃事务 ID，则这个事务在当前事务之前就已经被提交了，对 creator 可见（因为比已提交的最大事务 ID 小的并不一定已经提交，所以应该判断是否在活跃事务列表） * db_trx_id >= max_trx_id：该版本对应的事务 ID 大于 Read view 中当前系统的最大事务 ID，则说明该数据是在当前 Read view 创建之后才产生的，对 creator 不可见 * min_trx_id<= db_trx_id < max_trx_id：判断 db_trx_id 是否在活跃事务列表 m_ids 中 @@ -6719,7 +6711,7 @@ Buffer Pool 的使用提高了读写数据的效率，但是如果 MySQL 宕机 * redo log **记录数据页的物理修改**，而不是某一行或某几行的修改，用来恢复提交后的数据页，只能**恢复到最后一次提交**的位置 * redo log 采用的是 WAL（Write-ahead logging，**预写式日志**），所有修改要先写入日志，再更新到磁盘，保证了数据不会因 MySQL 宕机而丢失，从而满足了持久性要求 -* 简单的 redo log 是纯粹的物理日志，负责的 redo log 会存在物理日志和逻辑日志 +* 简单的 redo log 是纯粹的物理日志，复杂的 redo log 会存在物理日志和逻辑日志 工作过程：MySQL 发生了宕机，InnoDB 会判断一个数据页在崩溃恢复时丢失了更新，就会将它读到内存，然后根据 redo log 内容更新内存，更新完成后，内存页变成脏页，然后进行刷脏 @@ -6745,15 +6737,15 @@ Buffer Pool 的使用提高了读写数据的效率，但是如果 MySQL 宕机 log buffer 被划分为若干 redo log block（块，类似数据页的概念），每个默认大小 512 字节，每个 block 由 12 字节的 log block head、496 字节的 log block body、4 字节的 log block trailer 组成 * 当数据修改时，先修改 Change Buffer 中的数据，然后在 redo log buffer 记录这次操作，写入 log buffer 的过程是**顺序写入**的（先写入前面的 block，写满后继续写下一个） -* log buffer 中有一个指针 buf_free，来标识该位置之前都是填满的 block，该位置之后都是空闲区域（**碰撞指针**） +* log buffer 中有一个指针 buf_free，来标识该位置之前都是填满的 block，该位置之后都是空闲区域 MySQL 规定对底层页面的一次原子访问称为一个 Mini-Transaction（MTR），比如在 B+ 树上插入一条数据就算一个 MTR * 一个事务包含若干个 MTR，一个 MTR 对应一组若干条 redo log，一组 redo log 是不可分割的，在进行数据恢复时也把一组 redo log 当作一个不可分割的整体处理 -* 所以不是每生成一条 redo 日志就将其插入到 log buffer 中，而是一个 MTR 结束后**将一组 redo 日志写入 log buffer** +* 不是每生成一条 redo 日志就将其插入到 log buffer 中，而是一个 MTR 结束后**将一组 redo 日志写入** -InnoDB 的 redo log 是**固定大小**的，redo 日志在磁盘中以文件组的形式存储，同一组中的每个文件大小一样格式一样， +InnoDB 的 redo log 是**固定大小**的，redo 日志在磁盘中以文件组的形式存储，同一组中的每个文件大小一样格式一样 * `innodb_log_group_home_dir` 代表磁盘存储 redo log 的文件目录，默认是当前数据目录 * `innodb_log_file_size` 代表文件大小，默认 48M，`innodb_log_files_in_group` 代表文件个数，默认 2 最大 100，所以日志的文件大小为 `innodb_log_file_size * innodb_log_files_in_group` @@ -6770,10 +6762,10 @@ redo 日志文件也是由若干个 512 字节的 block 组成，日志文件的 ##### 日志刷盘 -redo log 需要在事务提交时将日志写入磁盘，但是比将内存中的 Buffer Pool 修改的数据写入磁盘的速度快，原因： +redo log 需要在事务提交时将日志写入磁盘，但是比 Buffer Pool 修改的数据写入磁盘的速度快，原因： * 刷脏是随机 IO，因为每次修改的数据位置随机；redo log 和 binlog 都是**顺序写**，磁盘的顺序 IO 比随机 IO 速度要快 -* 刷脏是以数据页（Page）为单位的，一个页上的一个小修改都要整页写入；redo log 中只包含真正需要写入的部分，减少无效 IO +* 刷脏是以数据页（Page）为单位的，一个页上的一个小修改都要整页写入；redo log 中只包含真正需要写入的部分，好几页的数据修改可能只记录在一个 redo log 页中，减少无效 IO * **组提交机制**，可以大幅度降低磁盘的 IO 消耗 InnoDB 引擎会在适当的时候，把内存中 redo log buffer 持久化（fsync）到磁盘，具体的**刷盘策略**： @@ -6784,7 +6776,6 @@ InnoDB 引擎会在适当的时候，把内存中 redo log buffer 持久化（fs * 2：在事务提交时将缓冲区的 redo 日志异步写入到磁盘，不能保证提交时肯定会写入，只是有这个动作。日志已经在操作系统的缓存，如果操作系统没有宕机而 MySQL 宕机，也是可以恢复数据的 * 写入 redo log buffer 的日志超过了总容量的一半，就会将日志刷入到磁盘文件，这会影响执行效率，所以开发中应**避免大事务** * 服务器关闭时 -* checkpoint 时（下小节详解） * 并行的事务提交（组提交）时，会将将其他事务的 redo log 持久化到磁盘。假设事务 A 已经写入 redo log buffer 中，这时另外一个线程的事务 B 提交，如果 innodb_flush_log_at_trx_commit 设置的是 1，那么事务 B 要把 redo log buffer 里的日志全部持久化到磁盘，**因为多个事务共用一个 redo log buffer**，所以一次 fsync 可以刷盘多个事务的 redo log，提升了并发量 服务器启动后 redo 磁盘空间不变，所以 redo 磁盘中的日志文件是被**循环使用**的，采用循环写数据的方式，写完尾部重新写头部，所以要确保头部 log 对应的修改已经持久化到磁盘 @@ -6803,7 +6794,7 @@ lsn (log sequence number) 代表已经写入的 redo 日志量、flushed_to_disk MTR 的执行过程中修改过的页对应的控制块会加到 Buffer Pool 的 flush 链表中，链表中脏页是按照第一次修改的时间进行排序的（头插），控制块中有两个指针用来记录脏页被修改的时间： -* oldest_modification：第一次修改 Buffer Pool 中某个缓冲页时，将修改该页的 MTR **开始时**对应的 lsn 值写入这个属性，所以链表页是以该值进行排序的 +* oldest_modification：第一次修改 Buffer Pool 中某个缓冲页时，将修改该页的 MTR **开始时**对应的 lsn 值写入这个属性 * newest_modification：每次修改页面，都将 MTR 结束时全局的 lsn 值写入这个属性，所以该值是该页面最后一次修改后的 lsn 值 全局变量 checkpoint_lsn 表示**当前系统可以被覆盖的 redo 日志总量**，当 redo 日志对应的脏页已经被刷新到磁盘后，该文件空间就可以被覆盖重用，此时执行一次 checkpoint 来更新 checkpoint_lsn 的值存入管理信息（刷脏和执行一次 checkpoint 并不是同一个线程），该值的增量就代表磁盘文件中当前位置向后可以被覆盖的文件的量，所以该值是一直增大的 @@ -6836,10 +6827,8 @@ SHOW ENGINE INNODB STATUS\G 恢复的过程：按照 redo log 依次执行恢复数据，优化方式 -* 使用哈希表：根据 redo log 的 space ID 和 page number 属性计算出哈希值，将对同一页面的修改放入同一个槽里，可以一次性完成对某页的恢复，**避免了随机 IO** -* 跳过已经刷新到磁盘中的页面：数据页的 File Header 中的 FILE_PAGE_LSN 属性（类似 newest_modification）表示最近一次修改页面时的 lsn 值，如果在 checkpoint 后，数据页被刷新到磁盘中，那么该页 lsn 属性肯定大于 checkpoint_lsn - -总结：先写 redo buffer，在写 change buffer，先刷 redo log，再刷脏，在删除完成刷脏 redo log +* 使用哈希表：根据 redo log 的 space id 和 page number 属性计算出哈希值，将对同一页面的修改放入同一个槽里，可以一次性完成对某页的恢复，**避免了随机 IO** +* 跳过已经刷新到磁盘中的页面：数据页的 File Header 中的 FILE_PAGE_LSN 属性（类似 newest_modification）表示最近一次修改页面时的 lsn 值，数据页被刷新到磁盘中，那么该页 lsn 属性肯定大于 checkpoint_lsn @@ -6862,7 +6851,7 @@ MySQL 中还存在 binlog（二进制日志）也可以记录写操作并用于 * 内容不同：redo log 是物理日志，内容基于磁盘的 Page；binlog 的内容是二进制的，根据 binlog_format 参数的不同，可能基于SQL 语句、基于数据本身或者二者的混合（日志部分详解） * 写入时机不同：binlog 在事务提交时一次写入；redo log 的写入时机相对多元 -binlog 为什么不支持奔溃恢复？ +binlog 为什么不支持崩溃恢复？ * binlog 记录的是语句，并不记录数据页级的数据（哪个页改了哪些地方），所以没有能力恢复数据页 * binlog 是追加写，保存全量的日志，没有标志确定从哪个点开始的数据是已经刷盘了，而 redo log 只要在 checkpoint_lsn 后面的就是没有刷盘的 @@ -6877,14 +6866,14 @@ binlog 为什么不支持奔溃恢复？ 更新一条记录的过程：写之前一定先读 -* 在 B+ 树中定位到该记录（这个过程也被称作加锁读），如果该记录所在的页面不在 Buffer Pool 里，先将其加载进内存 +* 在 B+ 树中定位到该记录，如果该记录所在的页面不在 Buffer Pool 里，先将其加载进内存 * 首先更新该记录对应的聚簇索引，更新聚簇索引记录时： * 更新记录前向 undo 页面写 undo 日志，由于这是更改页面，所以需要记录一下相应的 redo 日志 - 注意：修改 undo页面也是在**修改页面**，事务凡是修改页面就需要先记录相应的 redo 日志 + 注意：修改 undo 页面也是在**修改页面**，事务只要修改页面就需要先记录相应的 redo 日志 - * 然后**先记录对应的的 redo 日志**（等待 MTR 提交后写入 redo log buffer），**最后进行真正的更新记录** + * 然后**记录对应的 redo 日志**（等待 MTR 提交后写入 redo log buffer），**最后进行真正的更新记录** * 更新其他的二级索引记录，不会再记录 undo log，只记录 redo log 到 buffer 中 @@ -6925,7 +6914,7 @@ update T set c=c+1 where ID=2; * Prepare 阶段：存储引擎将该事务的 **redo 日志刷盘**，并且将本事务的状态设置为 PREPARE，代表执行完成随时可以提交事务 * Commit 阶段：先将事务执行过程中产生的 binlog 刷新到硬盘，再执行存储引擎的提交工作，引擎把 redo log 改成提交状态 -redo log 和 binlog 都可以用于表示事务的提交状态，而**两阶段提交就是让这两个状态保持逻辑上的一致**，也有利于主从复制，更好的保持主从数据的一致性 +存储引擎层的 redo log 和 server 层的 binlog 可以认为是一个分布式事务， 都可以用于表示事务的提交状态，而**两阶段提交就是让这两个状态保持逻辑上的一致**，也有利于主从复制，更好的保持主从数据的一致性 @@ -6937,12 +6926,12 @@ redo log 和 binlog 都可以用于表示事务的提交状态，而**两阶段 系统崩溃前没有提交的事务的 redo log 可能已经刷盘（定时线程或者 checkpoint），怎么处理崩溃恢复？ -工作流程：通过 undo log 在服务器重启时将未提交的事务回滚掉。首先定位到 128 个回滚段遍历 slot，获取 undo 链表首节点页面的 undo segement header 中的 TRX_UNDO_STATE 属性，表示当前链表的事务属性，事务状态是活跃的就全部回滚，如果是 PREPARE 状态，就需要根据 binlog 的状态进行判断： +工作流程：获取 undo 链表首节点页面的 undo segement header 中的 TRX_UNDO_STATE 属性，表示当前链表的事务属性，**事务状态是活跃（未提交）的就全部回滚**，如果是 PREPARE 状态，就需要根据 binlog 的状态进行判断： * 如果在时刻 A 发生了崩溃（crash），由于此时 binlog 还没完成，所以需要进行回滚 * 如果在时刻 B 发生了崩溃，redo log 和 binlog 有一个共**同的数据字段叫 XID**，崩溃恢复的时候，会按顺序扫描 redo log： * 如果 redo log 里面的事务是完整的，也就是已经有了 commit 标识，说明 binlog 也已经记录完整，直接从 redo log 恢复数据 - * 如果 redo log 里面的事务只有 prepare，就根据 XID 去 binlog 中判断对应的事务是否存在并完整，如果完整可以恢复数据，提交事务 + * 如果 redo log 里面的事务只有 prepare，就根据 XID 去 binlog 中判断对应的事务是否存在并完整，如果完整可以恢复数据 判断一个事务的 binlog 是否完整的方法： @@ -7281,7 +7270,7 @@ InnoDB 与 MyISAM 的最大不同有两点：一是支持事务；二是采用 行级锁，也称为记录锁（Record Lock），InnoDB 实现了以下两种类型的行锁： - 共享锁 (S)：又称为读锁，简称 S 锁，多个事务对于同一数据可以共享一把锁，都能访问到数据，但是只能读不能修改 -- 排他锁 (X)：又称为写锁，简称 X 锁，不能与其他锁并存，如一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁，包括共享锁和排他锁，只有获取排他锁的事务是可以对数据读取和修改 +- 排他锁 (X)：又称为写锁，简称 X 锁，不能与其他锁并存，获取排他锁的事务是可以对数据读取和修改 RR 隔离界别下，对于 UPDATE、DELETE 和 INSERT 语句，InnoDB 会**自动给涉及数据集加排他锁**（行锁），在 commit 时自动释放；对于普通 SELECT 语句，不会加任何锁（只是针对 InnoDB 层来说的，因为在 Server 层会**加 MDL 读锁**），通过 MVCC 防止并发冲突 @@ -7412,7 +7401,7 @@ InnoDB 会对间隙（GAP）进行加锁，就是间隙锁 （RR 隔离级别下 InnoDB 加锁的基本单位是 next-key lock，该锁是行锁和 gap lock 的组合（X or S 锁），但是加锁过程是分为间隙锁和行锁两段执行 -* 可以**保护当前记录和前面的间隙**，遵循左开右闭原则，单纯的是间隙锁左开右开 +* 可以**保护当前记录和前面的间隙**，遵循左开右闭原则，单纯的间隙锁是左开右开 * 假设有 10、11、13，那么可能的间隙锁包括：(负无穷,10]、(10,11]、(11,13]、(13,正无穷) 几种索引的加锁情况： @@ -7422,7 +7411,7 @@ InnoDB 加锁的基本单位是 next-key lock，该锁是行锁和 gap lock 的 * 范围查询无论是否是唯一索引，都需要访问到不满足条件的第一个值为止 * 对于联合索引且是唯一索引，如果 where 条件只包括联合索引的一部分，那么会加间隙锁 -间隙锁优点：RR 级别下间隙锁可以解决事务的一部分的**幻读问题**，通过对间隙加锁，可以防止读取过程中数据条目发生变化。一部分的意思是不会对全部间隙加锁，只能加锁一部分的间隙。 +间隙锁优点：RR 级别下间隙锁可以**解决事务的一部分的幻读问题**，通过对间隙加锁，可以防止读取过程中数据条目发生变化。一部分的意思是不会对全部间隙加锁，只能加锁一部分的间隙 间隙锁危害： @@ -7501,7 +7490,7 @@ InnoDB 为了支持多粒度的加锁，允许行锁和表锁同时存在，支 * 0：全部采用 AUTO_INC 锁 * 1：全部采用轻量级锁 -* 2：混合使用，在插入记录的数量确定是采用轻量级锁，不确定时采用 AUTO_INC 锁 +* 2：混合使用，在插入记录的数量确定时采用轻量级锁，不确定时采用 AUTO_INC 锁 @@ -7758,7 +7747,7 @@ MySQL 的主从之间维持了一个**长连接**。主库内部有一个线程 主从复制主要依赖的是 binlog，MySQL 默认是异步复制，需要三个线程： -- binlog thread：在主库事务提交时，负责把数据变更记录在二进制日志文件 binlog 中，并通知 slave 有数据更新 +- binlog thread：在主库事务提交时，把数据变更记录在日志文件 binlog 中，并通知 slave 有数据更新 - I/O thread：负责从主服务器上**拉取二进制日志**，并将 binlog 日志内容依次写到 relay log 中转日志的最末端，并将新的 binlog 文件名和 offset 记录到 master-info 文件中，以便下一次读取日志时从指定 binlog 日志文件及位置开始读取新的 binlog 日志内容 - SQL thread：监测本地 relay log 中新增了日志内容，读取中继日志并重做其中的 SQL 语句，从库在 relay-log.info 中记录当前应用中继日志的文件名和位点以便下一次执行 @@ -7842,7 +7831,7 @@ coordinator 就是原来的 SQL Thread，并行复制中它不再直接更新数 * 线程分配完成并不是立即执行，为了防止造成更新覆盖，更新同一 DB 的两个事务必须被分发到同一个工作线程 * 同一个事务不能被拆开，必须放到同一个工作线程 -MySQL 5.6 版本的策略：每个线程对应一个 hash 表，用于保存当前这个线程的执行队列里的事务所涉及的表，hash 表的 key 是数据库 名，value 是一个数字，表示队列中有多少个事务修改这个库，适用于主库上有多个 DB 的情况 +MySQL 5.6 版本的策略：每个线程对应一个 hash 表，用于保存当前这个线程的执行队列里的事务所涉及的表，hash 表的 key 是数据库名，value 是一个数字，表示队列中有多少个事务修改这个库，适用于主库上有多个 DB 的情况 每个事务在分发的时候，跟线程的**冲突**（事务操作的是同一个库）关系包括以下三种情况： @@ -7852,7 +7841,7 @@ MySQL 5.6 版本的策略：每个线程对应一个 hash 表，用于保存当 优缺点： -* 构造 hash 值的时候很快，只需要库名，而且一个实例上 DB 数也不会很多，不会出现需要构造很多个项的情况 +* 构造 hash 值的时候很快，只需要库名，而且一个实例上 DB 数也不会很多，不会出现需要构造很多项的情况 * 不要求 binlog 的格式，statement 格式的 binlog 也可以很容易拿到库名（日志章节详解了 binlog） * 主库上的表都放在同一个 DB 里面，这个策略就没有效果了；或者不同 DB 的热点不同，比如一个是业务逻辑库，一个是系统配置库，那也起不到并行的效果，需要**把相同热度的表均匀分到这些不同的 DB 中**，才可以使用这个策略 @@ -7983,7 +7972,7 @@ SELECT master_pos_wait(file, pos[, timeout]); * 选定一个从库执行判断位点语句，如果返回值是 >=0 的正整数，说明从库已经同步完事务，可以在这个从库执行查询语句 * 如果出现其他情况，需要到主库执行查询语句 -注意：如果所有的从库都延迟超过 timeout 秒，查询压力就都跑到主库上，所以需要进行权衡 +注意：如果所有的从库都延迟超过 timeout 秒，查询压力就都跑到主库上，所以需要进行权衡 @@ -8285,7 +8274,7 @@ GTID=source_id:transaction_id * source_id：是一个实例第一次启动时自动生成的，是一个全局唯一的值 * transaction_id：初始值是 1，每次提交事务的时候分配给这个事务，并加 1，是连续的（区分事务 ID，事务 ID 是在执行时生成） -启动 MySQL 实例时，加上参数 `gtid_mode=on` 和 `enforce_gtid_consistency=on` 就可以启动 GTID 模式，每个事务都会和一个 GTID 一一对应，每个 MySQL 实例都维护了一个 **GTID 集合**，用来对应当前实例执行过的所有事务 +启动 MySQL 实例时，加上参数 `gtid_mode=on` 和 `enforce_gtid_consistency=on` 就可以启动 GTID 模式，每个事务都会和一个 GTID 一一对应，每个 MySQL 实例都维护了一个 GTID 集合，用来存储当前实例**执行过的所有事务** GTID 有两种生成方式，使用哪种方式取决于 session 变量 gtid_next： @@ -8353,7 +8342,7 @@ GTID 有两种生成方式，使用哪种方式取决于 session 变量 gtid_nex ### 日志分类 -在任何一种数据库中，都会有各种各样的日志，记录着数据库工作的过程，可以帮助数据库管理员追踪数据库曾经发生过的各种事件。 +在任何一种数据库中，都会有各种各样的日志，记录着数据库工作的过程，可以帮助数据库管理员追踪数据库曾经发生过的各种事件 MySQL日志主要包括六种： @@ -8554,7 +8543,7 @@ mysqlbinlog log-file; #### 数据恢复 -误删库或者表时，需要根据 binlog 进行数据恢复， +误删库或者表时，需要根据 binlog 进行数据恢复 一般情况下数据库有定时的全量备份，假如每天 0 点定时备份，12 点误删了库，恢复流程： @@ -8607,7 +8596,7 @@ SELECT * FROM tb_book WHERE id < 8 ### 慢日志 -慢查询日志记录所有执行时间超过 long_query_time 并且扫描记录数不小于 min_examined_row_limit 的所有的 SQL 语句的日志。long_query_time 默认为 10 秒，最小为 0， 精度到微秒 +慢查询日志记录所有执行时间超过 long_query_time 并且扫描记录数不小于 min_examined_row_limit 的所有的 SQL 语句的日志long_query_time 默认为 10 秒，最小为 0， 精度到微秒 慢查询日志默认是关闭的，可以通过两个参数来控制慢查询日志，配置文件 `/etc/mysql/my.cnf`： @@ -8743,9 +8732,9 @@ long_query_time=10 ### 概述 -NoSQL（Not-Only SQL）：泛指非关系型的数据库，作为关系型数据库的补充。 +NoSQL（Not-Only SQL）：泛指非关系型的数据库，作为关系型数据库的补充 -MySQL 支持 ACID 特性，保证可靠性和持久性，读取性能不高，因此需要缓存的来减缓数据库的访问压力。 +MySQL 支持 ACID 特性，保证可靠性和持久性，读取性能不高，因此需要缓存的来减缓数据库的访问压力 作用：应对基于海量用户和海量数据前提下的数据处理问题 @@ -8764,8 +8753,6 @@ MySQL 支持 ACID 特性，保证可靠性和持久性，读取性能不高， 参考视频：https://www.bilibili.com/video/BV1CJ411m7Gc -参考视频：https://www.bilibili.com/video/BV1Rv41177Af - *** @@ -8790,17 +8777,6 @@ Redis (REmote DIctionary Server) ：用 C 语言开发的一个开源的高性 * 有序集合类型：zset/sorted_set（TreeSet） * 支持持久化，可以进行数据灾难恢复 -应用： - -* 为热点数据加速查询（主要场景），如热点商品、热点新闻、热点资讯、推广类等高访问量信息等 - -* 即时信息查询，如排行榜、网站访问统计、公交到站信息、在线人数（聊天室、网站）、设备信号等 - -* 时效性信息控制，如验证码控制、投票控制等 - -* 分布式数据共享，如分布式集群架构中的 session 分离 -* 消息队列 - *** @@ -8809,56 +8785,6 @@ Redis (REmote DIctionary Server) ：用 C 语言开发的一个开源的高性 ### 安装启动 -#### CentOS - -1. 下载 Redis - - 下载安装包： - - ```sh - wget http://download.redis.io/releases/redis-5.0.0.tar.gz - ``` - - 解压安装包： - - ```sh - tar –xvf redis-5.0.0.tar.gz - ``` - - 编译（在解压的目录中执行）： - - ```sh - make - ``` - - 安装（在解压的目录中执行）： - - ```sh - make install - ``` - - - -2. 安装 Redis - - redis-server，服务器启动命令 客户端启动命令 - - redis-cli，redis核心配置文件 - - redis.conf，RDB文件检查工具（快照持久化文件） - - redis-check-dump，AOF文件修复工具 - - redis-check-aof - - - -*** - - - -#### Ubuntu - 安装： * Redis 5.0 被包含在默认的 Ubuntu 20.04 软件源中 @@ -8868,7 +8794,7 @@ Redis (REmote DIctionary Server) ：用 C 语言开发的一个开源的高性 sudo apt install redis-server ``` -* 检查Redis状态 +* 检查 Redis 状态 ```sh sudo systemctl status redis-server @@ -8923,7 +8849,7 @@ Redis (REmote DIctionary Server) ：用 C 语言开发的一个开源的高性 mkdir data ``` -2. 创建配置文件副本放入 conf 目录，Ubuntu系统配置文件 redis.conf 在目录 `/etc/redis` 中 +2. 创建配置文件副本放入 conf 目录，Ubuntu 系统配置文件 redis.conf 在目录 `/etc/redis` 中 ```sh cat redis.conf | grep -v "#" | grep -v "^$" -> /conf/redis-6379.conf @@ -9019,7 +8945,7 @@ Redis (REmote DIctionary Server) ：用 C 语言开发的一个开源的高性 logfile filename ``` -注意：日志级别开发期设置为 verbose 即可，生产环境中配置为 notice，简化日志输出量，降低写日志IO的频度 +注意：日志级别开发期设置为 verbose 即可，生产环境中配置为 notice，简化日志输出量，降低写日志 IO 的频度 @@ -9145,7 +9071,7 @@ redis[1]> #### key space -Redis 是一个键值对（key-value pair）数据库服务器，每个数据库都由一个 redisDb 结构表示，redisDb.dict 字典中保存了数据库的所有键值对，将这个字典称为键空间（key space） +Redis 是一个键值对（key-value pair）数据库服务器，每个数据库都由一个 redisDb 结构表示，redisDb.dict **字典中保存了数据库的所有键值对**，将这个字典称为键空间（key space） ```c typedef struct redisDB { @@ -9209,8 +9135,10 @@ typedef struct redisDB { keys pattern #查询key ``` - 查询模式规则：* 匹配任意数量的任意符号、? 配合一个任意符号、[] 匹配一个指定符号 + KEYS 命令需要**遍历存储的键值对**，操作延时高，一般不被建议用于生产环境中 + 查询模式规则：* 匹配任意数量的任意符号、? 配合一个任意符号、[] 匹配一个指定符号 + ```sh keys * #查询所有key keys aa* #查询所有以aa开头 @@ -9225,13 +9153,11 @@ typedef struct redisDB { ```sh type key #获取key的类型 - sort key [ASC/DESC] #对key中数据排序，默认对数字排序，并不更改集合中的数据位置，只是查询 - sort key alpha #对key中字母排序 dbsize #获取当前数据库的数据总量，即key的个数 flushdb #清除当前数据库的所有数据(慎用) flushall #清除所有数据(慎用) ``` - + 在执行 FLUSHDB 这样的危险命令之前，最好先执行一个 SELECT 命令，保证当前所操作的数据库是目标数据库 @@ -9322,7 +9248,7 @@ Redis 通过过期字典可以检查一个给定键是否过期： * AOF 重写，会对数据库中的键进行检查，忽略已经过期的键 * 复制：当服务器运行在复制模式下时，从服务器的过期键删除动作由主服务器控制 * 主服务器在删除一个过期键之后，会显式地向所有从服务器发送一个 DEL 命令，告知从服务器删除这个过期键 - * 从服务器在执行客户端发送的读命令时，即使碰到过期键也不会将过期键删除，会当作未过期键处理，只有在接到主服务器发来的 DEL 命令之后，才会删除过期键 + * 从服务器在执行客户端发送的读命令时，即使碰到过期键也不会将过期键删除，会当作未过期键处理，只有在接到主服务器发来的 DEL 命令之后，才会删除过期键（数据不一致） @@ -9341,7 +9267,7 @@ Redis 通过过期字典可以检查一个给定键是否过期： 针对过期数据有三种删除策略： - 定时删除 -- 惰性删除 +- 惰性删除（被动删除） - 定期删除 Redis 采用惰性删除和定期删除策略的结合使用 @@ -9396,15 +9322,13 @@ Redis 采用惰性删除和定期删除策略的结合使用 * 如果删除操作执行得太频繁，或者执行时间太长，就会退化成定时删除策略，将 CPU 时间过多地消耗在删除过期键上 * 如果删除操作执行得太少，或者执行时间太短，定期删除策略又会和惰性删除策略一样，出现浪费内存的情况 -所以采用定期删除策略的话，服务器必须根据情况合理地设置删除操作的执行时长和执行频率 - 定期删除是**周期性轮询 Redis 库中的时效性**数据，从过期字典中随机抽取一部分键检查，利用过期数据占比的方式控制删除频度 - Redis 启动服务器初始化时，读取配置 server.hz 的值，默认为 10，执行指令 info server 可以查看，每秒钟执行 server.hz 次 `serverCron() → activeExpireCycle()` - activeExpireCycle() 对某个数据库中的每个 expires 进行检测，工作模式： - * 轮询每个数据库，从数据库中取出一定数量的随机键进行检查，并删除其中的过期键 + * 轮询每个数据库，从数据库中取出一定数量的随机键进行检查，并删除其中的过期键，如果过期 key 的比例超过了 25%，则继续重复此过程，直到过期 key 的比例下降到 25% 以下，或者这次任务的执行耗时超过了 25 毫秒 * 全局变量 current_db 用于记录 activeExpireCycle() 的检查进度（哪一个数据库），下一次调用时接着该进度处理 * 随着函数的不断执行，服务器中的所有数据库都会被检查一遍，这时将 current_db 重置为 0，然后再次开始新一轮的检查 @@ -9417,6 +9341,8 @@ Redis 采用惰性删除和定期删除策略的结合使用 + + *** @@ -9499,6 +9425,221 @@ Redis 如果不设置最大内存大小或者设置最大内存大小为 0，在 +*** + + + +### 排序机制 + +#### 基本介绍 + +Redis 的 SORT 命令可以对列表键、集合键或者有序集合键的值进行排序，并不更改集合中的数据位置，只是查询 + +```sh +SORT key [ASC/DESC] #对key中数据排序，默认对数字排序，并不更改集合中的数据位置，只是查询 +SORT key ALPHA #对key中字母排序，按照字典序 +``` + + + + + +*** + + + +#### SORT + +`SORT ` 命令可以对一个包含数字值的键 key 进行排序 + +假设 `RPUSH numbers 3 1 2`，执行 `SORT numbers` 的详细步骤： + +* 创建一个和 key 列表长度相同的数组，数组每项都是 redisSortObject 结构 + + ```c + typedef struct redisSortObject { + // 被排序键的值 + robj *obj; + + // 权重 + union { + // 排序数字值时使用 + double score; + // 排序带有 BY 选项的字符串 + robj *cmpobj; + } u; + } + ``` + +* 遍历数组，将各个数组项的 obj 指针分别指向 numbers 列表的各个项 + +* 遍历数组，将 obj 指针所指向的列表项转换成一个 double 类型的浮点数，并将浮点数保存在对应数组项的 u.score 属性里 + +* 根据数组项 u.score 属性的值，对数组进行数字值排序，排序后的数组项按 u.score 属性的值**从小到大排列** + +* 遍历数组，将各个数组项的 obj 指针所指向的值作为排序结果返回给客户端，程序首先访问数组的索引 0，依次向后访问 + +![](https://seazean.oss-cn-beijing.aliyuncs.com/img/DB/Redis-sort排序.png) + +对于 `SORT key [ASC/DESC]` 函数： + +* 在执行升序排序时，排序算法使用的对比函数产生升序对比结果 +* 在执行降序排序时，排序算法使用的对比函数产生降序对比结果 + + + +**** + + + +#### BY + +SORT 命令默认使用被排序键中包含的元素作为排序的权重，元素本身决定了元素在排序之后所处的位置，通过使用 BY 选项，SORT 命令可以指定某些字符串键，或者某个哈希键所包含的某些域（field）来作为元素的权重，对一个键进行排序 + +```sh +SORT BY # 数值 +SORT BY ALPHA # 字符 +``` + +```sh +redis> SADD fruits "apple" "banana" "cherry" +(integer) 3 +redis> SORT fruits ALPHA +1) "apple" +2) "banana" +3) "cherry" +``` + +```sh +redis> MSET apple-price 8 banana-price 5.5 cherry-price 7 +OK +# 使用水果的价钱进行排序 +redis> SORT fruits BY *-price +1) "banana" +2) "cherry" +3) "apple" +``` + +实现原理：排序时的 u.score 属性就会被设置为对应的权重 + + + + + +*** + + + +#### LIMIT + +SORT 命令默认会将排序后的所有元素都返回给客户端，通过 LIMIT 选项可以让 SORT 命令只返回其中一部分已排序的元素 + +```sh +LIMIT +``` + +* offset 参数表示要跳过的已排序元素数量 +* count 参数表示跳过给定数量的元素后，要返回的已排序元素数量 + +```sh +# 对应 a b c d e f g +redis> SORT alphabet ALPHA LIMIT 2 3 +1) "c" +2) "d" +3) "e" +``` + +实现原理：在排序后的 redisSortObject 结构数组中，将指针移动到数组的索引 2 上，依次访问 array[2]、array[3]、array[4] 这 3 个数组项，并将数组项的 obj 指针所指向的元素返回给客户端 + + + + + +*** + + + +#### GET + +SORT 命令默认在对键进行排序后，返回被排序键本身所包含的元素，通过使用 GET 选项， 可以在对键进行排序后，根据被排序的元素以及 GET 选项所指定的模式，查找并返回某些键的值 + +```sh +SORT GET +``` + +```sh +redis> SADD students "tom" "jack" "sea" +#设置全名 +redis> SET tom-name "Tom Li" +OK +redis> SET jack-name "Jack Wang" +OK +redis> SET sea-name "Sea Zhang" +OK +``` + +```sh +redis> SORT students ALPHA GET *-name +1) "Jack Wang" +2) "Sea Zhang" +3) "Tom Li" +``` + +实现原理：对 students 进行排序后，对于 jack 元素和 *-name 模式，查找程序返回键 jack-name，然后获取 jack-name 键对应的值 + + + + + +*** + + + +#### STORE + +SORT 命令默认只向客户端返回排序结果，而不保存排序结果，通过使用 STORE 选项可以将排序结果保存在指定的键里面 + +```sh +SORT STORE +``` + +```sh +redis> SADD students "tom" "jack" "sea" +(integer) 3 +redis> SORT students ALPHA STORE sorted_students +(integer) 3 +``` + +实现原理：排序后，检查 sorted_students 键是否存在，如果存在就删除该键，设置 sorted_students 为空白的列表键，遍历排序数组将元素依次放入 + + + + + +*** + + + +#### 执行顺序 + +调用 SORT 命令，除了 GET 选项之外，改变其他选项的摆放顺序并不会影响命令执行选项的顺序 + +```sh +SORT ALPHA [ASC/DESC] BY LIMIT GET STORE +``` + +执行顺序： + +* 排序：命令会使用 ALPHA 、ASC 或 DESC、BY 这几个选项，对输入键进行排序，并得到一个排序结果集 +* 限制排序结果集的长度：使用 LIMIT 选项，对排序结果集的长度进行限制 +* 获取外部键：根据排序结果集中的元素以及 GET 选项指定的模式，查找并获取指定键的值，并用这些值来作为新的排序结果集 +* 保存排序结果集：使用 STORE 选项，将排序结果集保存到指定的键上面去 +* 向客户端返回排序结果集：最后一步命令遍历排序结果集，并依次向客户端返回排序结果集中的元素 + + + + + *** @@ -9527,8 +9668,8 @@ Redis 如果不设置最大内存大小或者设置最大内存大小为 0，在 * 如果给定的通知类型 type 不是服务器允许发送的通知类型，那么函数会直接返回 * 如果给定的通知是服务器允许发送的通知 - * 检测服务器是否允许发送键空间通知，如果允许程序就会构建并发送事件通知 - * 检测服务器是否允许发送键事件通知，如果允许程序就会构建并发送事件通知 + * 检测服务器是否允许发送键空间通知，允许就会构建并发送事件通知 + * 检测服务器是否允许发送键事件通知，允许就会构建并发送事件通知 @@ -9575,7 +9716,7 @@ Redis 基于 Reactor 模式开发了网络事件处理器，这个处理器被 -尽管多个文件事件可能会并发出现，但是 I/O 多路复用程序将所有产生事件的套接字处理请求放入一个**单线程的执行队列**中，通过队列有序、同步的向文件事件分派器传送套接字，上一个套接字产生的事件处理完后，才会继续向分派器传统下一个 +I/O 多路复用程序将所有产生事件的套接字处理请求放入一个**单线程的执行队列**中，通过队列有序、同步的向文件事件分派器传送套接字，上一个套接字产生的事件处理完后，才会继续向分派器传送下一个 @@ -9594,7 +9735,7 @@ Redis 单线程也能高效的原因： ##### 多路复用 -Redis 的 I/O 多路复用程序的所有功能都是通过包装常见的 select 、epoll、 evport 和 kqueue 这些函数库来实现的，Redis在 I/O 多路复用程序的实现源码中用 #include 宏定义了相应的规则，编译时自动选择系统中**性能最高的多路复用函数**来作为底层实现 +Redis 的 I/O 多路复用程序的所有功能都是通过包装常见的 select 、epoll、 evport 和 kqueue 这些函数库来实现的，Redis 在 I/O 多路复用程序的实现源码中用 #include 宏定义了相应的规则，编译时自动选择系统中**性能最高的多路复用函数**来作为底层实现 I/O 多路复用程序监听多个套接字的 AE_READABLE 事件和 AE_WRITABLE 事件，这两类事件和套接字操作之间的对应关系如下： @@ -9621,9 +9762,9 @@ Redis 为文件事件编写了多个处理器，这些事件处理器分别用 Redis 客户端与服务器进行连接并发送命令的整个过程： * Redis 服务器正在运作监听套接字的 AE_READABLE 事件，关联连接应答处理器 -* 当 Redis 客户端向服务器发起连接，监听套接字将产生 AE_READABLE 事件，触发连接应答处理器执行，对客户端的连接请求进行应答，创建客户端套接字以及客户端状态，并将客户端套接字的 AE_READABLE 事件与命令请求处理器进行关联 +* 当 Redis 客户端向服务器发起连接，监听套接字将产生 AE_READABLE 事件，触发连接应答处理器执行，对客户端的连接请求进行应答，创建客户端套接字以及客户端状态，并将客户端套接字的 **AE_READABLE 事件与命令请求处理器**进行关联 * 客户端向服务器发送命令请求，客户端套接字产生 AE_READABLE 事件，引发命令请求处理器执行，读取客户端的命令内容传给相关程序去执行 -* 执行命令会产生相应的命令回复，为了将这些命令回复传送回客户端，服务器会将客户端套接字的 AE_WRITABLE 事件与命令回复处理器进行关联 +* 执行命令会产生相应的命令回复，为了将这些命令回复传送回客户端，服务器会将客户端套接字的 **AE_WRITABLE 事件与命令回复处理器**进行关联 * 当客户端尝试读取命令回复时，客户端套接字产生 AE_WRITABLE 事件，触发命令回复处理器执行，在命令回复全部写入套接字后，服务器就会解除客户端套接字的 AE_WRITABLE 事件与命令回复处理器之间的关联 @@ -9660,8 +9801,6 @@ Redis 的时间事件分为以下两类： 无序链表并不影响时间事件处理器的性能，因为正常模式下的 Redis 服务器**只使用 serverCron 一个时间事件**，在 benchmark 模式下服务器也只使用两个时间事件，所以无序链表不会影响服务器的性能，几乎可以按照一个指针处理 -服务器 → serverCron 详解该时间事件 - *** @@ -9673,18 +9812,6 @@ Redis 的时间事件分为以下两类： 服务器中同时存在文件事件和时间事件两种事件类型，调度伪代码： ```python -# Redis 服务器的主函数的伪代码 -def main(): - # 初始化服务器 - init_server() - - # 循环处理事件，直到服务器关闭 - while server_is_not_shutdown(): - aeProcessEvents() - - # 服务器关闭 - clean_server() - # 事件调度伪代码 def aeProcessEvents(): # 获取到达时间离当前时间最接近的时间事件 @@ -9710,11 +9837,9 @@ def aeProcessEvents(): 事件的调度和执行规则： * aeApiPoll 函数的最大阻塞时间由到达时间最接近当前时间的时间事件决定，可以避免服务器对时间事件进行频繁的轮询（忙等待），也可以确保 aeApiPoll 函数不会阻塞过长时间 -* 文件事件是随机出现的，如果等待并处理完一次文件事件后仍未有任何时间事件到达，那么服务器将再次等待并处理文件事件。随着文件事件的不断执行，会逐渐向时间事件所设置的到达时间逼近，并最终来到到达时间，这时就可以开始处理时间事件 * 对文件事件和时间事件的处理都是**同步、有序、原子地执行**，服务器不会中途中断事件处理，也不会对事件进行抢占，所以两种处理器都要尽可地减少程序的阻塞时间，并在有需要时**主动让出执行权**，从而降低事件饥饿的可能性 * 命令回复处理器在写入字节数超过了某个预设常量，就会主动用 break 跳出写入循环，将余下的数据留到下次再写 * 时间事件也会将非常耗时的持久化操作放到子线程或者子进程执行 - * 时间事件在文件事件之后执行，并且事件之间不会出现抢占，所以时间事件的实际处理时间通常会比设定的到达时间稍晚 @@ -9830,9 +9955,7 @@ typedef struct redisClient { 客户端状态包括两类属性 * 一类是比较通用的属性，这些属性很少与特定功能相关，无论客户端执行的是什么工作，都要用到这些属性 -* 另一类是和特定功能相关的属性，比如操作数据库时用到的 db 属性和 dict id属性，执行事务时用到的 mstate 属性，以及执行 WATCH 命令时用到的 watched_keys 属性等，代码中没有列出 - - +* 另一类是和特定功能相关的属性，比如操作数据库时用到的 db 属性和 dict id 属性，执行事务时用到的 mstate 属性，以及执行 WATCH 命令时用到的 watched_keys 属性等，代码中没有列出 @@ -9880,24 +10003,12 @@ typedef struct redisClient { 一部分标志记录目前**客户端所处的状态**： -* REDIS_MONITOR 表示客户端正在执行 MONITOR 命令 * REDIS_UNIX_SOCKET 表示服务器使用 UNIX 套接字来连接客户端 * REDIS_BLOCKED 表示客户端正在被 BRPOP、BLPOP 等命令阻塞 -* REDIS_UNBLOCKED 表示客户端已经从 REDIS_BLOCKED 所表示的阻塞状态脱离，该标志只能在 REDIS_BLOCKED 标志已经打开的情况下使用 +* REDIS_UNBLOCKED 表示客户端已经从 REDIS_BLOCKED 所表示的阻塞状态脱离，在 REDIS_BLOCKED 标志打开的情况下使用 * REDIS_MULTI 标志表示客户端正在执行事务 * REDIS_DIRTY_CAS 表示事务使用 WATCH 命令监视的数据库键已经被修改 -* REDIS_DIRTY_EXEC 表示事务在命令入队时出现了错误。以上两个标志都表示事务的安全性已经被破坏，只要两个标记中的任意一个被打开，EXEC 命令必然会执行失败，这两个标志只能在客户端打开了 REDIS_MULTI 标志的情况下使用 -* REDIS_CLOSE_ASAP 表示客户端的输出缓冲区大小超出了服务器允许的范围，服务器会在下 一次执行 serverCron 函数时关闭这个客户端，防止服务器的稳定性受到这个客户端影响，积存在输出缓冲区中的所有内容会被**直接释放**，不会返回给客户端 -* REDIS_CLOSE_AFTER_REPLY 表示有用户对这个客户端执行了 `CLIENT KILL` 命令，或者客户端发送给服务器的命令请求中包含了错误的协议内容，服务器会将客户端积存在输出缓冲区中的所有内容发送给客户端，然后关闭客户端 -* REDIS_ASKING 表示客户端向集群节点（运行在集群模式下的服务器）发送了 `ASKING` 命令 -* REDIS_FORCE_AOF 表示强制服务器将当前执行的命令写入到 AOF 文件里，执行 `PUBSUB` 命令会使客户端打开该标志 -* REDIS_FORCE_REPL 表示强制主服务器将当前执行的命令复制给所有从服务器，执行 `SCRIPT LOAD` 命令会使客户端打开 REDIS_FORCE_AOF 标志和 REDIS_FORCE_REPL 标志 -* REDIS_MASTER_FORCE_REPLY 表示将要进行主从复制，在主从服务器进行命令传播期间，从服务器需要向主服务器发送 `REPLICATION ACK` 命令，在发送这个命令之前从服务器必须打开主服务器对应的客户端的该标志，否则发送操作会被拒绝执行 - -Redis 只会将对数据库进行了修改的命令写入到 AOF 文件，并复制到各个从服务器，但是 PUBSUB 和 SCRIPT LOAD 命令例外： - -* PUBSUB 命令虽然没有修改数据库，但 PUBSUB 命令向频道的所有订阅者发送消息这一行为带有副作用，接收到消息的所有客户端的状态都会因为这个命令而改变，所以服务器需要使用 REDIS_FORCE_AOF 标志强制将这个命令写入 AOF 文件。这样在将来载入 AOF 文件时，服务器就可以再次执行相同的 PUBSUB 命令，并产生相同的副作用 -* SCRIPT LOAD 命令虽然没有修改数据库，但它修改了服务器状态，所以也是一个带有副作用的命令，需要使用 REDIS_FORCE_AOF +* ..... @@ -10003,7 +10114,7 @@ obuf_soft_limit_reached_time 属性记录了**输出缓冲区第一次到达软 服务器使用不同的方式来创建和关闭不同类型的客户端 -如果客户端是通过网络连接与服务器进行连接的普通客户端，那么在客户端使用 connect 函数连接到服务器时，服务器就会调用连接事件处理器为客户端创建相应的客户端状态，并将这个新的客户端状态添加到服务器状态结构 clients 链表的末尾 +如果客户端是通过网络连接与服务器进行连接的普通客户端，那么在客户端使用 connect 函数连接到服务器时，服务器就会调用连接应答处理器为客户端创建相应的客户端状态，并将这个新的客户端状态添加到服务器状态结构 clients 链表的末尾 ![](https://seazean.oss-cn-beijing.aliyuncs.com/img/DB/Redis-服务器clients链表.png) @@ -10044,7 +10155,7 @@ lua_client 伪客户端在服务器运行的整个生命周期会一直存在， 理论上来说，可变缓冲区可以保存任意长的命令回复，但是为了回复过大占用过多的服务器资源，服务器会时刻检查客户端的输出缓冲区的大小，并在缓冲区的大小超出范围时，执行相应的限制操作： -* 硬性限制 (hard limit)：输出缓冲区的大小超过了硬性限制所设置的大小，那么服务器立即关闭客户端 +* 硬性限制 (hard limit)：输出缓冲区的大小超过了硬性限制所设置的大小，那么服务器会关闭客户端（serverCron 函数中执行），积存在输出缓冲区中的所有内容会被**直接释放**，不会返回给客户端 * 软性限制 (soft limit)：输出缓冲区的大小超过了软性限制所设置的大小，小于硬性限制的大小，服务器的操作： * 用属性 obuf_soft_limit_reached_time 记录下客户端到达软性限制的起始时间，继续监视客户端 * 如果输出缓冲区的大小一直超出软性限制，并且持续时间超过服务器设定的时长，那么服务器将关闭客户端 @@ -10107,7 +10218,7 @@ SET KEY VALUE -> # 命令 命令执行器开始对命令操作： -* 查找命令：首先根据客户端状态的 argv[0] 参数，在命令表 (command table) 中查找参数所指定的命令，并将找到的命令保存到客户端状态的 cmd 属性里面，是一个 redisCommand 结构 +* 查找命令：首先根据客户端状态的 argv[0] 参数，在**命令表 (command table)** 中查找参数所指定的命令，并将找到的命令保存到客户端状态的 cmd 属性里面，是一个 redisCommand 结构 命令查找算法与字母的大小写无关，所以命令名字的大小写不影响命令表的查找结果 @@ -10129,10 +10240,10 @@ SET KEY VALUE -> # 命令 * 如果服务器开启了慢查询日志功能，那么慢查询日志模块会检查是否需要为刚刚执行完的命令请求添加一条新的慢查询日志 * 根据执行命令所耗费的时长，更新命令的 redisCommand 结构的 milliseconds 属性，并将命令 calls 计数器的值增一 - * 如果服务器开启了 AOF 持久化功能，那么 AOF 持久化模块会将刚刚执行的命令请求写入到 AOF 缓冲区里面 - * 如果有其他从服务器正在复制当前这个服务器，那么服务器会将刚刚执行的命令传播给所有从服务器 + * 如果服务器开启了 AOF 持久化功能，那么 AOF 持久化模块会将执行的命令请求写入到 AOF 缓冲区里面 + * 如果有其他从服务器正在复制当前这个服务器，那么服务器会将执行的命令传播给所有从服务器 -* 将命令回复发送给客户端：客户端套接字变为可写状态时，服务器就会执行命令回复处理器，将客户端输出缓冲区中的命令回复发送给客户端，发送完毕之后回复处理器会清空客户端状态的输出缓冲区，为处理下一个命令请求做好准备 +* 将命令回复发送给客户端：客户端**套接字变为可写状态**时，服务器就会执行命令回复处理器，将客户端输出缓冲区中的命令回复发送给客户端，发送完毕之后回复处理器会清空客户端状态的输出缓冲区，为处理下一个命令请求做好准备 @@ -10185,7 +10296,7 @@ struct redisCommand { ##### 基本介绍 -Redis 服务器以周期性事件的方式来运行 serverCron 函数，服务器初始化时读取配置 server.hz 的值，默认为 10，代表每秒钟执行 10 次，即每隔 100 毫秒执行一次，执行指令 info server 可以查看 +Redis 服务器以周期性事件的方式来运行 serverCron 函数，服务器初始化时读取配置 server.hz 的值，默认为 10，代表每秒钟执行 10 次，即**每隔 100 毫秒执行一次**，执行指令 info server 可以查看 serverCron 函数负责定期对自身的资源和状态进行检查和调整，从而确保服务器可以长期、稳定地运行 @@ -10354,7 +10465,7 @@ clientsCron 函数对一定数量的客户端进行以下两个检查： * 如果客户端与服务器之间的连接巳经超时（很长一段时间客户端和服务器都没有互动），那么程序释放这个客户端 * 如果客户端在上一次执行命令请求之后，输入缓冲区的大小超过了一定的长度，那么程序会释放客户端当前的输入缓冲区，并重新创建一个默认大小的输入缓冲区，从而防止客户端的输入缓冲区耗费了过多的内存 -databasesCron 函数会对服务器中的一部分数据库进行检查，删除其中的过期键，并在有需要时 对字典进行收缩操作 +databasesCron 函数会对服务器中的一部分数据库进行检查，删除其中的过期键，并在有需要时对字典进行收缩操作 @@ -10364,7 +10475,7 @@ databasesCron 函数会对服务器中的一部分数据库进行检查，删除 ##### 持久状态 -服务器状态中记录执行 BGSAVE 命令和 BGREWRITEAOF 命令的子进程的 ID， +服务器状态中记录执行 BGSAVE 命令和 BGREWRITEAOF 命令的子进程的 ID ```c struct redisServer { @@ -10417,7 +10528,7 @@ serverCron 函数会检查 BGSAVE 或者 BGREWRITEAOF 命令是否正在执行 -##### cronloops +##### 执行次数 服务器状态的 cronloops 属性记录了 serverCron 函数执行的次数 @@ -10436,7 +10547,7 @@ struct redisServer { ##### 缓冲限制 -服务器会关闭那些输入或者输出缓冲区大小超出限制的客户端 +服务器会关闭那些输入或者输出**缓冲区大小超出限制**的客户端 @@ -10469,7 +10580,7 @@ struct redisServer { initServer 还进行了非常重要的设置操作： * 为服务器设置进程信号处理器 -* 创建共享对象，包含 OK、ERR、整数 1 到 10000 的字符串对象等 +* 创建共享对象，包含 OK、ERR、**整数 1 到 10000 的字符串对象**等 * **打开服务器的监听端口** * **为 serverCron 函数创建时间事件**， 等待服务器正式运行时执行 serverCron 函数 * 如果 AOF 持久化功能已经打开，那么打开现有的 AOF 文件，如果 AOF 文件不存在，那么创建并打开一个新的 AOF 文件 ，为 AOF 写入做好准备 @@ -10516,6 +10627,98 @@ initServer 还进行了非常重要的设置操作： +***** + + + +### 慢日志 + +#### 基本介绍 + +Redis 的慢查询日志功能用于记录执行时间超过给定时长的命令请求，通过产生的日志来监视和优化查询速度 + +服务器配置有两个和慢查询日志相关的选项： + +* slowlog-log-slower-than 选项指定执行时间超过多少微秒的命令请求会被记录到日志上 +* slowlog-max-len 选项指定服务器最多保存多少条慢查询日志 + +服务器使用先进先出 FIFO 的方式保存多条慢查询日志，当服务器存储的慢查询日志数量等于 slowlog-max-len 选项的值时，在添加一条新的慢查询日志之前，会先将最旧的一条慢查询日志删除 + +配置选项可以通过 CONFIG SET option value 命令进行设置 + +常用命令： + +```sh +SLOWLOG GET [n] # 查看 n 条服务器保存的慢日志 +SLOWLOG LEN # 查看日志数量 +SLOWLOG RESET # 清除所有慢查询日志 +``` + + + +*** + + + +#### 日志保存 + +服务器状态中包含了慢查询日志功能有关的属性： + +```c +struct redisServer { + // 下一条慢查询日志的ID + long long slowlog_entry_id; + + // 保存了所有慢查询日志的链表 + list *slowlog; + + // 服务器配置选项的值 + long long slowlog-log-slower-than; + // 服务器配置选项的值 + unsigned long slowlog_max_len; +} +``` + +slowlog_entry_id 属性的初始值为 0，每当创建一条新的慢查询日志时，这个属性就会用作新日志的 id 值，之后该属性增一 + +slowlog 链表保存了服务器中的所有慢查询日志，链表中的每个节点是一个 slowlogEntry 结构， 代表一条慢查询日志： + +```c +typedef struct slowlogEntry { + // 唯一标识符 + long long id; + // 命令执行时的时间，格式为UNIX时间戳 + time_t time; + // 执行命令消耗的时间，以微秒为单位 + long long duration; + // 命令与命令参数 + robj **argv; + // 命令与命令参数的数量 + int argc; +} +``` + + + + + +*** + + + +#### 添加日志 + +在每次执行命令的前后，程序都会记录微秒格式的当前 UNIX 时间戳，两个时间之差就是执行命令所耗费的时长，函数会检查命令的执行时长是否超过 slowlog-log-slower-than 选项所设置： + +* 如果是的话，就为命令创建一个新的日志，并将新日志添加到 slowlog 链表的表头 +* 检查慢查询日志的长度是否超过 slowlog-max-len 选项所设置的长度，如果是将多出来的日志从 slowlog 链表中删除掉 + +* 将 redisServer. slowlog_entry_id 的值增 1 + + + + + *** @@ -10543,7 +10746,7 @@ struct sdshdr { }; ``` -SDS 遵循 C 字符串**以空字符结尾**的惯例， 保存空字符的 1 字节不计算在 len 属性，SDS 会自动为空字符分配额外的 1 字节空间和添加空字符到字符串末尾，所以空字符对于 SDS 的使用者来说是完全透明的 +SDS 遵循 C 字符串**以空字符结尾**的惯例，保存空字符的 1 字节不计算在 len 属性，SDS 会自动为空字符分配额外的 1 字节空间和添加空字符到字符串末尾，所以空字符对于 SDS 的使用者来说是完全透明的 ![](https://seazean.oss-cn-beijing.aliyuncs.com/img/DB/Redis-SDS底层结构.png) @@ -10573,7 +10776,7 @@ SDS 遵循 C 字符串**以空字符结尾**的惯例， 保存空字符的 1 二进制安全： * C 字符串中的字符必须符合某种编码（比如 ASCII）方式，除了字符串末尾以外其他位置不能包含空字符，否则会被误认为是字符串的结尾，所以只能保存文本数据 -* SDS 的 API 都是二进制安全的，使用字节数组 buf 保存一系列的二进制数据，使用 len 属性来判断数据的结尾，所以可以保存图片、视频、压缩文件等二进制数据 +* SDS 的 API 都是二进制安全的，使用字节数组 buf 保存一系列的二进制数据，**使用 len 属性来判断数据的结尾**，所以可以保存图片、视频、压缩文件等二进制数据 兼容 C 字符串的函数：SDS 会在为 buf 数组分配空间时多分配一个字节来保存空字符，所以可以重用一部分 C 字符串函数库的函数 @@ -10589,9 +10792,9 @@ C 字符串**每次**增长或者缩短都会进行一次内存重分配，拼 SDS 通过未使用空间解除了字符串长度和底层数组长度之间的关联，在 SDS 中 buf 数组的长度不一定就是字符数量加一， 数组里面可以包含未使用的字节，字节的数量由 free 属性记录 -内存重分配涉及复杂的算法，需要执行系统调用，是一个比较耗时的操作，SDS 的两种优化策略： +内存重分配涉及复杂的算法，需要执行**系统调用**，是一个比较耗时的操作，SDS 的两种优化策略： -* 空间预分配：当 SDS 的 API 进行修改并且需要进行空间扩展时，程序不仅会为 SDS 分配修改所必需的空间， 还会为 SDS 分配额外的未使用空间 +* 空间预分配：当 SDS 需要进行空间扩展时，程序不仅会为 SDS 分配修改所必需的空间， 还会为 SDS 分配额外的未使用空间 * 对 SDS 修改之后，SDS 的长度（len 属性）小于 1MB，程序分配和 len 属性同样大小的未使用空间，此时 len 和 free 相等 @@ -10603,7 +10806,7 @@ SDS 通过未使用空间解除了字符串长度和底层数组长度之间的 在扩展 SDS 空间前，API 会先检查 free 空间是否足够，如果足够就无需执行内存重分配，所以通过预分配策略，SDS 将连续增长 N 次字符串所需内存的重分配次数从**必定 N 次降低为最多 N 次** -* 惰性空间释放：当 SDS 的 API 需要缩短字符串时，程序并不立即使用内存重分配来回收缩短后多出来的字节，而是使用 free 属性将这些字节的数量记录起来，并等待将来使用 +* 惰性空间释放：当 SDS 缩短字符串时，程序并不立即使用内存重分配来回收缩短后多出来的字节，而是使用 free 属性将这些字节的数量记录起来，并等待将来复用 SDS 提供了相应的 API 来真正释放 SDS 的未使用空间，所以不用担心空间惰性释放策略造成的内存浪费问题 @@ -10802,7 +11005,7 @@ load_factor = ht[0].used / ht[0].size 原因：执行该命令的过程中，Redis 需要创建当前服务器进程的子进程，而大多数操作系统都采用写时复制（copy-on­-write）技术来优化子进程的使用效率，通过提高执行扩展操作的负载因子，尽可能地避免在子进程存在期间进行哈希表扩展操作，可以避免不必要的内存写入操作，最大限度地节约内存 -哈希表执行收缩的条件：负载因子小于 0.1（自动执行，servreCron 中检测），缩小为字典中数据个数的 50% 左右 +哈希表执行收缩的条件：负载因子小于 0.1（自动执行，servreCron 中检测） @@ -10818,7 +11021,7 @@ load_factor = ht[0].used / ht[0].size * 如果执行的是扩展操作，ht[1] 的大小为第一个大于等于 $ht[0].used * 2$ 的 $2^n$ * 如果执行的是收缩操作，ht[1] 的大小为第一个大于等于 $ht[0].used$ 的 $2^n$ * 将保存在 ht[0] 中所有的键值对重新计算哈希值和索引值，迁移到 ht[1] 上 -* 当 ht[0] 包含的所有键值对都迁移到了 ht[1] 之后（ht[0]变为空表）， 释放 ht[0]，将 ht[1] 设置为 ht[0]，并在 ht[1] 创建一个新的空白哈希表，为下一次 rehash 做准备 +* 当 ht[0] 包含的所有键值对都迁移到了 ht[1] 之后（ht[0] 变为空表），释放 ht[0]，将 ht[1] 设置为 ht[0]，并在 ht[1] 创建一个新的空白哈希表，为下一次 rehash 做准备 如果哈希表里保存的键值对数量很少，rehash 就可以在瞬间完成，但是如果哈希表里数据很多，那么要一次性将这些键值对全部 rehash 到 ht[1] 需要大量计算，可能会导致服务器在一段时间内停止服务 @@ -10826,10 +11029,10 @@ Redis 对 rehash 做了优化，使 rehash 的动作并不是一次性、集中 * 为 ht[1] 分配空间，此时字典同时持有 ht[0] 和 ht[1] 两个哈希表 * 在字典中维护了一个索引计数器变量 rehashidx，并将变量的值设为 0，表示 rehash 正式开始 -* 在 rehash 进行期间，每次对字典执行添加、删除、查找或者更新操作时，程序除了执行指定的操作以外，还会顺带将 ht[0] 哈希表在 rehashidx 索引上的所有键值对 rehash 到 ht[1]，rehash 完成之后**将 rehashidx 属性的值增一** -* 随着字典操作的不断执行，最终在某个时间点上 ht[0] 的所有键值对都被 rehash 至 ht[1]，这时程序将 rehashidx 属性的值设为 -1，表示 rehash 操作已完成 +* 在 rehash 进行期间，每次对字典执行增删改查操作时，程序除了执行指定的操作以外，还会顺带将 ht[0] 哈希表在 rehashidx 索引上的所有键值对 rehash 到 ht[1]，rehash 完成之后**将 rehashidx 属性的值增一** +* 随着字典操作的不断执行，最终在某个时间点 ht[0] 的所有键值对都被 rehash 至 ht[1]，将 rehashidx 属性的值设为 -1 -渐进式 rehash 采用分而治之的方式，将 rehash 键值对所需的计算工作均摊到对字典的每个添加、删除、查找和更新操作上，从而避免了集中式 rehash 带来的庞大计算量 +渐进式 rehash 采用**分而治之**的方式，将 rehash 键值对所需的计算工作均摊到对字典的每个添加、删除、查找和更新操作上，从而避免了集中式 rehash 带来的庞大计算量 渐进式 rehash 期间的哈希表操作： @@ -10900,23 +11103,23 @@ typedef struct zskiplistNode { 层：level 数组包含多个元素，每个元素包含指向其他节点的指针。根据幕次定律（power law，越大的数出现的概率越小）**随机**生成一个介于 1 和 32 之间的值（Redis5 之后最大为 64）作为 level 数组的大小，这个大小就是层的高度，节点的第一层是 level[0] = L1 -前进指针：forward 用于从表头到表尾方向正序（升序）遍历节点，遇到 NULL 停止遍历 +前进指针：forward 用于从表头到表尾方向**正序（升序）遍历节点**，遇到 NULL 停止遍历 -跨度：span 用于记录两个节点之间的距离，用来**计算排位（rank）**： +跨度：span 用于记录两个节点之间的距离，用来计算排位（rank）： * 两个节点之间的跨度越大相距的就越远，指向 NULL 的所有前进指针的跨度都为 0 -* 在查找某个节点的过程中，将沿途访问过的所有层的跨度累计起来，结果就是目标节点在跳跃表中的排位，按照上图所示： +* 在查找某个节点的过程中，**将沿途访问过的所有层的跨度累计起来，结果就是目标节点在跳跃表中的排位**，按照上图所示： 查找分值为 3.0 的节点，沿途经历的层：查找的过程只经过了一个层，并且层的跨度为 3，所以目标节点在跳跃表中的排位为 3 查找分值为 2.0 的节点，沿途经历的层：经过了两个跨度为 1 的节点，因此可以计算出目标节点在跳跃表中的排位为 2 -后退指针：backward 用于从表尾到表头方向逆序（降序）遍历节点 +后退指针：backward 用于从表尾到表头方向**逆序（降序）遍历节点** 分值：score 属性一个 double 类型的浮点数，跳跃表中的所有节点都按分值从小到大来排序 -成员对象：obj 属性是一个指针，指向一个 SDS 字符串对象。同一个跳跃表中，各个节点保存的成员对象必须是唯一的，但是多个节点保存的分值可以是相同的，分值相同的节点将按照成员对象在字典序中的大小来进行排序（从小到大） +成员对象：obj 属性是一个指针，指向一个 SDS 字符串对象。同一个跳跃表中，各个节点保存的**成员对象必须是唯一的**，但是多个节点保存的分值可以是相同的，分值相同的节点将按照成员对象在字典序中的大小来进行排序（从小到大） @@ -10961,7 +11164,7 @@ encoding 取值为三种：INTSET_ENC_INT16、INTSET_ENC_INT32、INTSET_ENC_INT6 -#### 升级降级 +#### 类型升级 整数集合添加的新元素的类型比集合现有所有元素的类型都要长时，需要先进行升级（upgrade），升级流程： @@ -10988,7 +11191,7 @@ encoding 取值为三种：INTSET_ENC_INT16、INTSET_ENC_INT32、INTSET_ENC_INT6 * 节约内存：要让数组可以同时保存 int16、int32、int64 三种类型的值，可以直接使用 int64_t 类型的数组作为整数集合的底层实现，但是会造成内存浪费，整数集合可以确保升级操作只会在有需要的时候进行，尽量节省内存 -整数集合不支持降级操作，一旦对数组进行了升级，编码就会一直保持升级后的状态 +整数集合**不支持降级操作**，一旦对数组进行了升级，编码就会一直保持升级后的状态 @@ -11006,7 +11209,7 @@ encoding 取值为三种：INTSET_ENC_INT16、INTSET_ENC_INT32、INTSET_ENC_INT6 ![](https://seazean.oss-cn-beijing.aliyuncs.com/img/DB/Redis-压缩列表底层结构.png) -* zlbytes：uint32_t 类型 4 字节，记录整个压缩列表占用的内存字节数，在对压缩列表进行内存重分或者计算 zlend 的位置时使用 +* zlbytes：uint32_t 类型 4 字节，记录整个压缩列表占用的内存字节数，在对压缩列表进行内存重分配或者计算 zlend 的位置时使用 * zltail：uint32_t 类型 4 字节，记录压缩列表表尾节点距离起始地址有多少字节，通过这个偏移量程序无须遍历整个压缩列表就可以确定表尾节点的地址 * zllen：uint16_t 类型 2 字节，记录了压缩列表包含的节点数量，当该属性的值小于 UINT16_MAX (65535) 时，该值就是压缩列表中节点的数量；当这个值等于 UINT16_MAX 时节点的真实数量需要遍历整个压缩列表才能计算得出 * entryX：列表节点，压缩列表中的各个节点，**节点的长度由节点保存的内容决定** @@ -11028,14 +11231,14 @@ encoding 取值为三种：INTSET_ENC_INT16、INTSET_ENC_INT32、INTSET_ENC_INT6 ![](https://seazean.oss-cn-beijing.aliyuncs.com/img/DB/Redis-压缩列表节点.png) -previous_entry_length：以字节为单位记录了压缩列表中前一个节点的长度，程序可以通过指针运算，根据当前节点的起始地址来计算出前一个节点的起始地址，完成从表尾向表头遍历操作 +previous_entry_length：以字节为单位记录了压缩列表中前一个节点的长度，程序可以通过指针运算，根据当前节点的起始地址来计算出前一个节点的起始地址，完成**从表尾向表头遍历**操作 * 如果前一节点的长度小于 254 字节，该属性的长度为 1 字节，前一节点的长度就保存在这一个字节里 * 如果前一节点的长度大于等于 254 字节，该属性的长度为 5 字节，其中第一字节会被设置为 0xFE（十进制 254），之后的四个字节则用于保存前一节点的长度 encoding：记录了节点的 content 属性所保存的数据类型和长度 -* 长度为 1 字节、2 字节或者 5 字节，值的最高位为 00、01 或者 10 的是字节数组编码，数组的长度由编码除去最高两位之后的其他位记录，下划线 `_` 表示留空，而 `b`、`x` 等变量则代表实际的二进制数据 +* **长度为 1 字节、2 字节或者 5 字节**，值的最高位为 00、01 或者 10 的是字节数组编码，数组的长度由编码除去最高两位之后的其他位记录，下划线 `_` 表示留空，而 `b`、`x` 等变量则代表实际的二进制数据 ![](https://seazean.oss-cn-beijing.aliyuncs.com/img/DB/Redis-压缩列表字节数组编码.png) @@ -11124,7 +11327,7 @@ typedef struct redisObiect { Redis 并没有直接使用数据结构来实现键值对数据库，而是基于这些数据结构创建了一个对象系统，包含字符串对象、列表对象、哈希对象、集合对象和有序集合对象这五种类型的对象，而每种对象又通过不同的编码映射到不同的底层数据结构 -Redis 自身是一个 Map，其中所有的数据都是采用 key : value 的形式存储，**键对象都是字符串对象**，而值对象有五种基本类型和三种高级类型对象 +Redis 是一个 Map 类型，其中所有的数据都是采用 key : value 的形式存储，**键对象都是字符串对象**，而值对象有五种基本类型和三种高级类型对象 ![](https://seazean.oss-cn-beijing.aliyuncs.com/img/DB/Redis-对象编码.png) @@ -11345,7 +11548,7 @@ Redis 所有操作都是**原子性**的，采用**单线程**机制，命令是 -#### 对象 +#### 实现 字符串对象的编码可以是 int、raw、embstr 三种 @@ -11882,8 +12085,8 @@ set 类型：与 hash 存储结构哈希表完全相同，只是仅存储键不 使用字典加跳跃表的优势： -* 字典为有序集合创建了一个从成员到分值的映射，用 O(1) 复杂度查找给定成员的分值 -* 排序操作使用跳跃表完成，节省每次重新排序带来的时间成本和空间成本 +* 字典为有序集合创建了一个**从成员到分值的映射**，用 O(1) 复杂度查找给定成员的分值 +* **排序操作使用跳跃表完成**，节省每次重新排序带来的时间成本和空间成本 使用 ziplist 格式存储需要满足以下两个条件： @@ -11892,6 +12095,11 @@ set 类型：与 hash 存储结构哈希表完全相同，只是仅存储键不 当元素比较多时，此时 ziplist 的读写效率会下降，时间复杂度是 O(n)，跳表的时间复杂度是 O(logn) +为什么用跳表而不用平衡树？ + +* 在做范围查找的时候，跳表操作简单（前进指针或后退指针），平衡树需要回旋查找 +* 跳表比平衡树实现简单，平衡树的插入和删除操作可能引发子树的旋转调整，而跳表的插入和删除只需要修改相邻节点的指针 + *** @@ -11914,59 +12122,64 @@ set 类型：与 hash 存储结构哈希表完全相同，只是仅存储键不 ### Bitmaps -#### 操作 +#### 基本操作 + +Bitmaps 是二进制位数组（bit array），底层使用 SDS 字符串表示，因为 SDS 是二进制安全的 -Bitmaps 本身不是一种数据类型， 实际上就是字符串（key-value） ， 但是它可以对字符串的位进行操作 +![](https://seazean.oss-cn-beijing.aliyuncs.com/img/DB/Redis-位数组结构.png) + +buf 数组的每个字节用一行表示，buf[1] 是 `'\0'`，保存位数组的顺序和书写位数组的顺序是完全相反的，图示的位数组 0100 1101 数据结构的详解查看 Java → Algorithm → 位图 -指令操作： -* 获取指定 key 对应**偏移量**上的 bit 值 - ```sh - getbit key offset - ``` -* 设置指定 key 对应偏移量上的 bit 值，value 只能是 1 或 0 - ```sh - setbit key offset value - ``` +*** -* 对指定 key 按位进行交、并、非、异或操作，并将结果保存到 destKey 中 - ```sh - bitop option destKey key1 [key2...] - ``` - option：and 交、or 并、not 非、xor 异或 +#### 命令实现 -* 统计指定 key 中1的数量 +##### GETBIT - ```sh - bitcount key [start end] - ``` +GETBIT 命令获取位数组 bitarray 在 offset 偏移量上的二进制位的值 + +```sh +GETBIT +``` +执行过程： +* 计算 `byte = offset/8`（向下取整）, byte 值记录数据保存在位数组中的索引 +* 计算 `bit = (offset mod 8) + 1`，bit 值记录数据在位数组中的第几个二进制位 +* 根据 byte 和 bit 值，在位数组 bitarray 中定位 offset 偏移量指定的二进制位，并返回这个位的值 -*** +GETBIT 命令执行的所有操作都可以在常数时间内完成，所以时间复杂度为 O(1) -#### 应用 +*** -- 解决 Redis 缓存穿透，判断给定数据是否存在， 防止缓存穿透 - -- 垃圾邮件过滤，对每一个发送邮件的地址进行判断是否在布隆的黑名单中，如果在就判断为垃圾邮件 +##### SETBIT -- 爬虫去重，爬给定网址的时候对已经爬取过的 URL 去重 +SETBIT 将位数组 bitarray 在 offset 偏移量上的二进制位的值设置为 value，并向客户端返回二进制位的旧值 -- 信息状态统计 +```sh +SETBIT +``` +执行过程： +* 计算 `len = offset/8 + 1`，len 值记录了保存该数据至少需要多少个字节 +* 检查 bitarray 键保存的位数组的长度是否小于 len，成立就会将 SDS 扩展为 len 字节（注意空间预分配机制），所有新扩展空间的二进制位的值置为 0 +* 计算 `byte = offset/8`（向下取整）, byte 值记录数据保存在位数组中的索引 +* 计算 `bit = (offset mod 8) + 1`，bit 值记录数据在位数组中的第几个二进制位 +* 根据 byte 和 bit 值，在位数组 bitarray 中定位 offset 偏移量指定的二进制位，首先将指定位现存的值保存在 oldvalue 变量，然后将新值 value 设置为这个二进制位的值 +* 向客户端返回 oldvalue 变量的值 @@ -11974,36 +12187,97 @@ Bitmaps 本身不是一种数据类型， 实际上就是字符串（key-value -### Hyper +##### BITCOUNT -基数是数据集去重后元素个数，HyperLogLog 是用来做基数统计的，运用了 LogLog 的算法 +BITCOUNT 命令用于统计给定位数组中，值为 1 的二进制位的数量 -```java -{1, 3, 5, 7, 5, 7, 8} 基数集： {1, 3, 5 ,7, 8} 基数：5 -{1, 1, 1, 1, 1, 7, 1} 基数集： {1,7} 基数：2 +```sh +BITCOUNT [start end] ``` -相关指令： +二进制位统计算法： -* 添加数据 +* 遍历法：遍历位数组中的每个二进制位 +* 查表算法：读取每个字节（8 位）的数据，查表获取数值对应的二进制中有几个 1 +* variable-precision SWAR算法：计算汉明距离 +* Redis 实现： + * 如果二进制位的数量大于等于 128 位， 那么使用 variable-precision SWAR 算法来计算二进制位的汉明重量 + * 如果二进制位的数量小于 128 位，那么使用查表算法来计算二进制位的汉明重量 - ```sh - pfadd key element [element ...] - ``` -* 统计数据 - ```sh - pfcount key [key ...] - ``` +**** -* 合并数据 - ```sh - pfmerge destkey sourcekey [sourcekey...] - ``` -应用场景： +##### BITOP + +BITOP 命令对指定 key 按位进行交、并、非、异或操作，并将结果保存到指定的键中 + +```sh +BITOP OPTION destKey key1 [key2...] +``` + +OPTION 有 AND（与）、OR（或）、 XOR（异或）和 NOT（非）四个选项 + +AND、OR、XOR 三个命令可以接受多个位数组作为输入，需要遍历输入的每个位数组的每个字节来进行计算，所以命令的复杂度为 O(n^2)；与此相反，NOT 命令只接受一个位数组输入，所以时间复杂度为 O(n) + + + +*** + + + +#### 应用场景 + +- **解决 Redis 缓存穿透**，判断给定数据是否存在， 防止缓存穿透 + + + +- 垃圾邮件过滤，对每一个发送邮件的地址进行判断是否在布隆的黑名单中，如果在就判断为垃圾邮件 + +- 爬虫去重，爬给定网址的时候对已经爬取过的 URL 去重 + +- 信息状态统计 + + + + + +*** + + + +### Hyper + +基数是数据集去重后元素个数，HyperLogLog 是用来做基数统计的，运用了 LogLog 的算法 + +```java +{1, 3, 5, 7, 5, 7, 8} 基数集： {1, 3, 5 ,7, 8} 基数：5 +{1, 1, 1, 1, 1, 7, 1} 基数集： {1,7} 基数：2 +``` + +相关指令： + +* 添加数据 + + ```sh + pfadd key element [element ...] + ``` + +* 统计数据 + + ```sh + pfcount key [key ...] + ``` + +* 合并数据 + + ```sh + pfmerge destkey sourcekey [sourcekey...] + ``` + +应用场景： * 用于进行基数统计，不是集合不保存数据，只记录数量而不是具体数据，比如网站的访问量 * 核心是基数估算算法，最终数值存在一定误差 @@ -12080,7 +12354,7 @@ AOF：将数据的操作过程进行保存，日志形式，存储操作过程 #### 文件创建 -RDB 持久化功能所生成的 RDB文件 是一个经过压缩的紧凑二进制文件，通过该文件可以还原生成 RDB 文件时的数据库状态，有两个 Redis 命令可以生成 RDB 文件，一个是 SAVE，另一个是 BGSAVE +RDB 持久化功能所生成的 RDB 文件是一个经过压缩的紧凑二进制文件，通过该文件可以还原生成 RDB 文件时的数据库状态，有两个 Redis 命令可以生成 RDB 文件，一个是 SAVE，另一个是 BGSAVE @@ -12113,7 +12387,7 @@ BGSAVE：bg 是 background，代表后台执行，命令的完成需要两个进 -流程：客户端发出 BGSAVE 指令，Redis 服务器使用 fork 函数创建一个子进程，然后响应后台已经开始执行的信息给客户端。子进程会去执行持久化的操作，持久化过程是先将数据写入到一个临时文件中，持久化操作结束再用这个临时文件**替换**上次持久化的文件 +流程：客户端发出 BGSAVE 指令，Redis 服务器使用 fork 函数创建一个子进程，然后响应后台已经开始执行的信息给客户端。子进程会异步执行持久化的操作，持久化过程是先将数据写入到一个临时文件中，持久化操作结束再用这个临时文件**替换**上次持久化的文件 ```python # 创建子进程 @@ -12148,7 +12422,7 @@ rdbchecksum yes|no * SAVE 命令会被服务器拒绝，服务器禁止 SAVE 和 BGSAVE 命令同时执行是为了避免父进程（服务器进程）和子进程同时执行两个 rdbSave 调用，产生竞争条件 * BGSAVE 命令也会被服务器拒绝，也会产生竞争条件 * BGREWRITEAOF 和 BGSAVE 两个命令不能同时执行 - * 如果 BGSAVE 命令正在执行，那么 BGREWRITEAOF 命令会被延迟到 BGSAVE 命令执行完毕之后执行 + * 如果 BGSAVE 命令正在执行，那么 BGREWRITEAOF 命令会被**延迟**到 BGSAVE 命令执行完毕之后执行 * 如果 BGREWRITEAOF 命令正在执行，那么 BGSAVE 命令会被服务器拒绝 @@ -12324,7 +12598,10 @@ AOF 写数据过程： +Redis 只会将对数据库进行了修改的命令写入到 AOF 文件，并复制到各个从服务器，但是 PUBSUB 和 SCRIPT LOAD 命令例外： +* PUBSUB 命令虽然没有修改数据库，但 PUBSUB 命令向频道的所有订阅者发送消息这一行为带有副作用，接收到消息的所有客户端的状态都会因为这个命令而改变，所以服务器需要使用 REDIS_FORCE_AOF 标志强制将这个命令写入 AOF 文件。这样在将来载入 AOF 文件时，服务器就可以再次执行相同的 PUBSUB 命令，并产生相同的副作用 +* SCRIPT LOAD 命令虽然没有修改数据库，但它修改了服务器状态，所以也是一个带有副作用的命令，需要使用 REDIS_FORCE_AOF @@ -12365,7 +12642,7 @@ struct redisServer { ##### 文件写入 -服务器在处理文件事件时可能会执行写命令，追加一些内容到 aof_buf 缓冲区里，所以服务器每次结束一个事件循环之前，就会执行 flushAppendOnlyFile 函数，判断是否需要**将 aof_buf 缓冲区中的内容写入和保存到 AOF 文件**里 +服务器在处理文件事件时会执行**写命令，追加一些内容到 aof_buf 缓冲区**里，所以服务器每次结束一个事件循环之前，就会执行 flushAppendOnlyFile 函数，判断是否需要**将 aof_buf 缓冲区中的内容写入和保存到 AOF 文件**里 flushAppendOnlyFile 函数的行为由服务器配置的 appendfsync 选项的值来决定 @@ -12378,12 +12655,12 @@ appendfsync always|everysec|no #AOF写数据策略：默认为everysec 特点：安全性最高，数据零误差，但是性能较低，不建议使用 -- everysec：先将 aof_buf 缓冲区中的内容写入到 AOF 文件，判断上次同步 AOF 文件的时间距离现在超过一秒钟，再次对 AOF 文件进行同步，这个同步操作是由一个（子）线程专门负责执行的 +- everysec：先将 aof_buf 缓冲区中的内容写入到操作系统缓存，判断上次同步 AOF 文件的时间距离现在超过一秒钟，再次进行同步 fsync，这个同步操作是由一个（子）线程专门负责执行的 特点：在系统突然宕机的情况下丢失 1 秒内的数据，准确性较高，性能较高，建议使用，也是默认配置 -- no：将 aof_buf 缓冲区中的内容写入到 AOF 文件，但并不对 AOF 文件进行同步，何时同步由操作系统来决定 +- no：将 aof_buf 缓冲区中的内容写入到操作系统缓存，但并不进行同步，何时同步由操作系统来决定 特点：**整体不可控**，服务器宕机会丢失上次同步 AOF 后的所有写指令 @@ -12446,8 +12723,6 @@ Redis 读取 AOF 文件并还原数据库状态的步骤： ##### 重写策略 -随着命令不断写入 AOF，文件会越来越大，很可能对 Redis 服务器甚至整个宿主计算机造成影响，为了解决这个问题 Redis 引入了 AOF 重写机制压缩文件体积 - AOF 重写：读取服务器当前的数据库状态，**生成新 AOF 文件来替换旧 AOF 文件**，不会对现有的 AOF 文件进行任何读取、分析或者写入操作，而是直接原子替换。新 AOF 文件不会包含任何浪费空间的冗余命令，所以体积通常会比旧 AOF 文件小得多 AOF 重写规则： @@ -12483,7 +12758,7 @@ bgrewriteaof * 子进程进行 AOF 重写期间，服务器进程（父进程）可以继续处理命令请求 -* 子进程带有服务器进程的数据副本，使用子进程而不是线程，可以在避免使用锁的情况下， 保证数据的安全性 +* 子进程带有服务器进程的数据副本，使用子进程而不是线程，可以在避免使用锁的情况下， 保证数据安全性 ![](https://seazean.oss-cn-beijing.aliyuncs.com/img/DB/Redis-AOF手动重写原理.png) @@ -12492,7 +12767,7 @@ bgrewriteaof 工作流程： * Redis 服务器执行完一个写命令，会同时将该命令追加到 AOF 缓冲区和 AOF 重写缓冲区（从创建子进程后才开始写入） -* 当子进程完成 AOF 重写工作之后，会向父进程发送一个信号，父进程在接到该信号之后， 会调用一个信号处理函数，该函数执行时会**对服务器进程（父进程）造成阻塞**（影响很小），主要工作： +* 当子进程完成 AOF 重写工作之后，会向父进程发送一个信号，父进程在接到该信号之后， 会调用一个信号处理函数，该函数执行时会**对服务器进程（父进程）造成阻塞**（影响很小，类似 JVM STW），主要工作： * 将 AOF 重写缓冲区中的所有内容写入到新 AOF 文件中， 这时新 AOF 文件所保存的状态将和服务器当前的数据库状态一致 * 对新的 AOF 文件进行改名，**原子地（atomic）覆盖**现有的 AOF 文件，完成新旧两个 AOF 文件的替换 @@ -12549,7 +12824,7 @@ RDB 的特点 AOF 特点： -* AOF 的优点：数据持久化有较好的实时性，通过 AOF 重写可以降低文件的体积 +* AOF 的优点：数据持久化有**较好的实时性**，通过 AOF 重写可以降低文件的体积 * AOF 的缺点：文件较大时恢复较慢 AOF 和 RDB 同时开启，系统默认取 AOF 的数据（数据不会存在丢失） @@ -12678,7 +12953,7 @@ int main(void) -在 p3224 和 p3225 执行完第二个循环后，main 函数退出，进程死亡。所以 p3226，p3227 就没有父进程了，成为孤儿进程，所以 p3226 和 p3227 的父进程就被置为 ID 为 1的 init 进程（笔记 Tool → Linux → 进程管理详解） +在 p3224 和 p3225 执行完第二个循环后，main 函数退出，进程死亡。所以 p3226，p3227 就没有父进程了，成为孤儿进程，所以 p3226 和 p3227 的父进程就被置为 ID 为 1 的 init 进程（笔记 Tool → Linux → 进程管理详解） 参考文章：https://blog.csdn.net/love_gaohz/article/details/41727415 @@ -12722,73 +12997,72 @@ vfork（虚拟内存 fork virtual memory fork）：调用 vfork() 父进程被 -## 事务机制 - -### 基本操作 - -Redis 事务的主要作用就是串联多个命令防止别的命令插队 - -* 开启事务 - - ```sh - multi #设定事务的开启位置，此指令执行后，后续的所有指令均加入到事务中 - ``` - -* 执行事务 - - ```sh - exec #设定事务的结束位置，同时执行事务，与multi成对出现，成对使用 - ``` - - 加入事务的命令暂时进入到任务队列中，并没有立即执行，只有执行 exec 命令才开始执行 -* 取消事务 - ```sh - discard #终止当前事务的定义，发生在multi之后，exec之前 - ``` +## 事务机制 - 一般用于事务执行过程中输入了错误的指令，直接取消这次事务，类似于回滚 +### 事务特征 -Redis 事务的三大特性： +Redis 事务就是将多个命令请求打包，然后**一次性、按顺序**地执行多个命令的机制，并且在事务执行期间，服务器不会中断事务去执行其他的命令请求，会将事务中的所有命令都执行完毕，然后才去处理其他客户端的命令请求，Redis 事务的特性： -* Redis 事务是一个单独的隔离操作，将一系列预定义命令包装成一个整体（一个队列），当执行时按照添加顺序依次执行，中间不会被打断或者干扰 * Redis 事务**没有隔离级别**的概念，队列中的命令在事务没有提交之前都不会实际被执行 * Redis 单条命令式保存原子性的，但是事务**不保证原子性**，事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚 + + *** ### 工作流程 -事务机制整体工作流程： +事务的执行流程分为三个阶段： -![](https://seazean.oss-cn-beijing.aliyuncs.com/img/DB/Redis-事务的工作流程.png) +* 事务开始：MULTI 命令的执行标志着事务的开始，通过在客户端状态的 flags 属性中打开 REDIS_MULTI 标识，将执行该命令的客户端从非事务状态切换至事务状态 -几种常见错误： + ```sh + MULTI # 设定事务的开启位置，此指令执行后，后续的所有指令均加入到事务中 + ``` -* 定义事务的过程中，命令格式输入错误，出现语法错误造成，**整体事务中所有命令均不会执行**，包括那些语法正确的命令 +* 命令入队：事务队列以先进先出（FIFO）的方式保存入队的命令，每个 Redis 客户端都有事务状态，包含着事务队列： - + ```c + typedef struct redisClient { + // 事务状态 + multiState mstate; /* MULTI/EXEC state */ + } + + typedef struct multiState { + // 事务队列，FIFO顺序 + multiCmd *commands; + + // 已入队命令计数 + int count； + } + ``` -* 定义事务的过程中，命令执行出现错误，例如对字符串进行 incr 操作，能够正确运行的命令会执行，运行错误的命令不会被执行 + * 如果命令为 EXEC、DISCARD、WATCH、MULTI 四个命中的一个，那么服务器立即执行这个命令 + * 其他命令服务器不执行，而是将命令放入一个事务队列里面，然后向客户端返回 QUEUED 回复 - +* 事务执行：EXEC 提交事务给服务器执行，服务器会遍历这个客户端的事务队列，执行队列中的命令并将执行结果返回 -* 已经执行完毕的命令对应的数据不会自动回滚，需要程序员在代码中实现回滚，应该尽可能避免： + ```sh + EXEC # Commit 提交，执行事务，与multi成对出现，成对使用 + ``` - 事务操作之前记录数据的状态 +事务取消的方法： - * 单数据：string - * 多数据：hash、list、set、zset +* 取消事务： + + ```sh + DISCARD # 终止当前事务的定义，发生在multi之后，exec之前 + ``` + + 一般用于事务执行过程中输入了错误的指令，直接取消这次事务，类似于回滚 - 设置指令恢复所有的被修改的项 - * 单数据：直接 set（注意周边属性，例如时效） - * 多数据：修改对应值或整体克隆复制 @@ -12796,97 +13070,77 @@ Redis 事务的三大特性： -### 监控锁 +### WATCH + +#### 监视机制 -对 key 添加监视锁，是一种乐观锁，在执行 exec 前如果其他客户端的操作导致 key 发生了变化，执行结果为 nil +WATCH 命令是一个乐观锁（optimistic locking），可以在 EXEC 命令执行之前，监视任意数量的数据库键，并在 EXEC 命令执行时，检查被监视的键是否至少有一个已经被修改过了，如果是服务器将拒绝执行事务，并向客户端返回代表事务执行失败的空回复 * 添加监控锁 ```sh - watch key1 [key2……] #可以监控一个或者多个key + WATCH key1 [key2……] #可以监控一个或者多个key ``` * 取消对所有 key 的监视 ```sh - unwatch + UNWATCH ``` -应用：基于状态控制的批量任务执行，防止其他线程对变量的修改 - *** -### 分布式锁 - -#### 基本操作 - -由于分布式系统多线程并发分布在不同机器上，这将使单机部署情况下的并发控制锁策略失效，需要分布式锁 - -Redis 分布式锁的基本使用，悲观锁 - -* 使用 setnx 设置一个公共锁 +#### 实现原理 - ```sh - setnx lock-key value # value任意数，返回为1设置成功，返回为0设置失败 - ``` +每个 Redis 数据库都保存着一个 watched_keys 字典，键是某个被 WATCH 监视的数据库键，值则是一个链表，记录了所有监视相应数据库键的客户端： - * 对于返回设置成功的，拥有控制权，进行下一步的具体业务操作 - * 对于返回设置失败的，不具有控制权，排队或等待 +```c +typedef struct redisDb { + // 正在被 WATCH 命令监视的键 + dict *watched_keys; +} +``` - `NX`：只在键不存在时，才对键进行设置操作，`SET key value NX` 效果等同于 `SETNX key value` +所有对数据库进行修改的命令，在执行后都会调用 `multi.c/touchWatchKey` 函数对 watched_keys 字典进行检查，是否有客户端正在监视刚被命令修改过的数据库键，如果有的话函数会将监视被修改键的客户端的 REDIS_DIRTY_CAS 标识打开，表示该客户端的事务安全性已经被破坏 - `XX` ：只在键已经存在时，才对键进行设置操作 +服务器接收到个客户端 EXEC 命令时，会根据这个客户端是否打开了 REDIS_DIRTY_CAS 标识，如果打开了说明客户端提交事务不安全，服务器会拒绝执行 - `EX`：设置键 key 的过期时间，单位时秒 - `PX`：设置键 key 的过期时间，单位时毫秒 - 说明：由于 `SET` 命令加上选项已经可以完全取代 SETNX、SETEX、PSETEX 的功能，Redis 不推荐使用这几个命令 -* 操作完毕通过 del 操作释放锁 - ```sh - del lock-key - ``` +**** -* 使用 expire 为锁 key 添加存活（持有）时间，过期自动删除（放弃）锁 - ```sh - expire lock-key second - pexpire lock-key milliseconds - ``` - - 通过 expire 设置过期时间缺乏原子性，如果在 setnx 和 expire 之间出现异常，锁也无法释放 - -* 在 set 时指定过期时间 - ```sh - SET key value [EX seconds | PX milliseconds] NX +### ACID -应用：解决抢购时出现超卖现象 +#### 原子性 +事务具有原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability） +原子性指事务队列中的命令要么就全部都执行，要么一个都不执行，但是在命令执行出错时，不会保证原子性（下一节详解） -**** +Redis 不支持事务回滚机制（rollback），即使事务队列中的某个命令在执行期间出现了错误，整个事务也会继续执行下去，直到将事务队列中的所有命令都执行完毕为止 +回滚需要程序员在代码中实现，应该尽可能避免： +* 事务操作之前记录数据的状态 -#### 防误删 + * 单数据：string -setnx 获取锁时，设置一个指定的唯一值（uuid），释放前获取这个值，判断是否自己的锁，防止出现线程之间误删了其他线程的锁 + * 多数据：hash、list、set、zset -```java -// 加锁, unique_value作为客户端唯一性的标识 -SET lock_key unique_value NX PX 10000 -``` -unique_value 是客户端的**唯一标识**，可以用一个随机生成的字符串来表示，PX 10000 则表示 lock_key 会在 10s 后过期，以免客户端在这期间发生异常而无法释放锁 +* 设置指令恢复所有的被修改的项 + * 单数据：直接 set（注意周边属性，例如时效） + * 多数据：修改对应值或整体克隆复制 @@ -12894,77 +13148,57 @@ unique_value 是客户端的**唯一标识**，可以用一个随机生成的字 -## 主从复制 - -### 基本介绍 +#### 一致性 -**三高**架构： +事务具有一致性指的是，数据库在执行事务之前是一致的，那么在事务执行之后，无论事务是否执行成功，数据库也应该仍然是一致的 -- 高并发：应用提供某一业务要能支持很多客户端同时访问的能力，称为并发 +一致是数据符合数据库的定义和要求，没有包含非法或者无效的错误数据，Redis 通过错误检测和简单的设计来保证事务的一致性： -- 高性能：性能带给我们最直观的感受就是速度快，时间短 +* 入队错误：命令格式输入错误，出现语法错误造成，**整体事务中所有命令均不会执行**，包括那些语法正确的命令 -- 高可用： - - 可用性：应用服务在全年宕机的时间加在一起就是全年应用服务不可用的时间 - - 业界可用性目标 5 个 9，即 99.999%，即服务器年宕机时长低于 315 秒，约 5.25 分钟 + -主从复制： +* 执行错误：命令执行出现错误，例如对字符串进行 incr 操作，事务中正确的命令会被执行，运行错误的命令不会被执行 -* 概念：将 master 中的数据即时、有效的复制到 slave 中 -* 特征：一个 master 可以拥有多个 slave，一个 slave 只对应一个 master -* 职责：master 和 slave 各自的职责不一样 + - master： - * **写数据**，执行写操作时，将出现变化的数据自动同步到 slave - * 读数据（可忽略） +* 服务器停机： - slave - * **读数据** - * 写数据（禁止） + * 如果服务器运行在无持久化的内存模式下，那么重启之后的数据库将是空白的，因此数据库是一致的 + * 如果服务器运行在持久化模式下，重启之后将数据库还原到一致的状态 -主从复制的机制： -* **薪火相传**：一个 slave 可以是下一个 slave 的 master，slave 同样可以接收其他 slave 的连接和同步请求，那么该 slave 作为了链条中下一个的 master, 可以有效减轻 master 的写压力，去中心化降低风险 - 注意：主机挂了，从机还是从机，无法写数据了 -* **反客为主**：当一个 master 宕机后，后面的 slave 可以立刻升为 master，其后面的 slave 不做任何修改 +*** - 将从机变为主机的命令：`slaveof no one` -主从复制的作用： -- **读写分离**：master 写、slave 读，提高服务器的读写负载能力 -- **负载均衡**：基于主从结构，配合读写分离，由 slave 分担 master 负载，并根据需求的变化，改变 slave 的数量，通过多个从节点分担数据读取负载，大大提高 Redis 服务器并发量与数据吞吐量 -- 故障恢复：当 master 出现问题时，由 slave 提供服务，实现快速的故障恢复 -- 数据冗余：实现数据热备份，是持久化之外的一种数据冗余方式 -- 高可用基石：基于主从复制，构建哨兵模式与集群，实现 Redis 的高可用方案 +#### 隔离性 -主从复制的应用场景： +Redis 是一个单线程的执行原理，所以对于隔离性，分以下两种情况： -* 机器故障：硬盘故障、系统崩溃，造成数据丢失，对业务形成灾难性打击，基本上会放弃使用redis +* 并发操作在 EXEC 命令前执行，隔离性的保证要使用 WATCH 机制来实现，否则隔离性无法保证 +* 并发操作在 EXEC 命令后执行，隔离性可以保证 -* 容量瓶颈：内存不足，放弃使用 Redis -* 解决方案：为了避免单点 Redis 服务器故障，准备多台服务器，互相连通。将数据复制多个副本保存在不同的服务器上连接在一起，并保证数据是同步的。即使有其中一台服务器宕机，其他服务器依然可以继续提供服务，实现 Redis 高可用，同时实现数据冗余备份 - +*** -*** +#### 持久性 +Redis 并没有为事务提供任何额外的持久化功能，事务的持久性由 Redis 所使用的持久化模式决定 +配置选项 `no-appendfsync-on-rewrite` 可以配合 appendfsync 选项在 AOF 持久化模式使用： -### 工作流程 +* 选项打开时在执行 BGSAVE 或者 BGREWRITEAOF 期间，服务器会暂时停止对 AOF 文件进行同步，从而尽可能地减少 I/O 阻塞 +* 选项打开时运行在 always 模式的 AOF 持久化，事务也不具有持久性，所以该选项默认关闭 -主从复制过程大体可以分为3个阶段 +在一个事务的最后加上 SAVE 命令总可以保证事务的耐久性 -* 建立连接阶段（即准备阶段） -* 数据同步阶段 -* 命令传播阶段 -![](https://seazean.oss-cn-beijing.aliyuncs.com/img/DB/Redis-主从复制工作流程.png) @@ -12972,192 +13206,159 @@ unique_value 是客户端的**唯一标识**，可以用一个随机生成的字 -### 建立连接 +## Lua 脚本 -#### 建立流程 +### 环境创建 -建立连接阶段：建立 slave 到 master 的连接，使 master 能够识别 slave，并保存 slave 端口号 +#### 基本介绍 -流程如下： +Redis 对 Lua 脚本支持，通过在服务器中嵌入 Lua 环境，客户端可以使用 Lua 脚本直接在服务器端**原子地执行**多个命令 -1. 设置 master 的地址和端口，保存 master 信息 -2. 建立 socket 连接 -3. 发送 ping 命令（定时器任务） -4. 身份验证（可能没有） -5. 发送 slave 端口信息 -6. 主从连接成功 +```sh +EVAL