<<MySQL实战45讲>> 笔记
1. 全字段排序
CREATE TABLE `t` (
`id` int(11) NOT NULL,
`city` varchar(16) NOT NULL,
`name` varchar(16) NOT NULL,
`age` int(11) NOT NULL,
`addr` varchar(128) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `city` (`city`)
) ENGINE=InnoDB;
Sql语句:
select city,name,age from t where city='杭州' order by name limit 1000;
Extra 这个字段中的“Using filesort”表示的就是需要排序,MySQL 会给每个线程分配一块内存用于排序,称为 sort_buffer。
通常情况下,这个语句执行流程如下所示 :
(1). 初始化 sort_buffer,确定放入 name、city、age 这三个字段;
(2). 从索引 city 找到第一个满足 city='杭州’条件的主键 id;
(3). 到主键 id 索引取出整行,取 name、city、age 三个字段的值,存入 sort_buffer 中;
(4). 从索引 city 取下一个记录的主键 id;重复步骤 3、4 直到 city 的值不满足查询条件为止;
(5). 对 sort_buffer 中的数据按照字段 name 做快速排序;按照排序结果取前 1000 行返回给客户端。
“按 name 排序”这个动作,可能在内存中完成,也可能需要使用外部排序,这取决于排序所需的内存和参数 sort_buffer_size。sort_buffer_size,就是 MySQL 为排序开辟的内存(sort_buffer)的大小。如果要排序的数据量小于 sort_buffer_size,排序就在内存中完成。但如果排序数据量太大,内存放不下,则不得不利用磁盘临时文件辅助排序。number_of_tmp_files 表示的是,排序过程中使用的临时文件数。外部排序一般使用归并排序算法。
2. rowid 排序
在上面这个算法过程里面,只对原表的数据读了一遍,剩下的操作都是在 sort_buffer 和临时文件中执行的。但这个算法有一个问题,就是如果查询要返回的字段很多的话,那么 sort_buffer 里面要放的字段数太多,这样内存里能够同时放下的行数很少,要分成很多个临时文件,排序的性能会很差。
接下来,修改如下参数:
SET max_length_for_sort_data = 16;
max_length_for_sort_data,是 MySQL 中专门控制用于排序的行数据的长度的一个参数。它的意思是,如果单行的长度超过这个值,MySQL 就认为单行太大,要换一个算法。
新的算法放入 sort_buffer 的字段,只有要排序的列(即 name 字段)和主键 id。
但这时,排序的结果就因为少了 city 和 age 字段的值,不能直接返回了,整个执行流程就变成如下所示的样子:
(1). 初始化 sort_buffer,确定放入两个字段,即 name 和 id;
(2). 从索引 city 找到第一个满足 city='杭州’条件的主键 id;
(3). 到主键 id 索引取出整行,取 name、id 这两个字段,存入 sort_buffer 中;
(4). 从索引 city 取下一个记录的主键 id;重复步骤 3、4 直到不满足 city='杭州’条件为止;
(5). 对 sort_buffer 中的数据按照字段 name 进行排序;遍历排序结果,取前 1000 行,并按照 id 的值回到原表中取出 city、name 和 age 三个字段返回给客户端。
3. 全字段排序 VS rowid 排序
如果 MySQL 实在是担心排序内存太小,会影响排序效率,才会采用 rowid 排序算法,这样排序过程中一次可以排序更多行,但是需要再回到原表去取数据。
如果 MySQL 认为内存足够大,会优先选择全字段排序,把需要的字段都放到 sort_buffer 中,这样排序后就会直接从内存里面返回查询结果了,不用再回到原表去取数据。
这也就体现了 MySQL 的一个设计思想:如果内存够,就要多利用内存,尽量减少磁盘访问。
对于 InnoDB 表来说,rowid 排序会要求回表多造成磁盘读,因此不会被优先选择。
4. 并不是所有的 order by 语句,都需要排序操作的
我们在这个数据表上创建一个 city 和 name 的联合索引,对应的 SQL 语句是:
alter table t add index city_user(city, name);
索引示意图:
在这个索引里面,我们依然可以用树搜索的方式定位到第一个满足 city='杭州’的记录,并且额外确保了,接下来按顺序取“下一条记录”的遍历过程中,只要 city 的值是杭州,name 的值就一定是有序的。
这样整个查询过程的流程就变成了:
(1). 从索引 (city,name) 找到第一个满足 city='杭州’条件的主键 id;
(2). 到主键 id 索引取出整行,取 name、city、age 三个字段的值,作为结果集的一部分直接返回;
(3). 从索引 (city,name) 取下一个记录主键 id;重复步骤 2、3,直到查到第 1000 条记录,或者是不满足 city='杭州’条件时循环结束。
Extra 字段中没有 Using filesort 了,也就是不需要排序了。
执行流程进一步简化:
覆盖索引是指,索引上的信息足够满足查询请求,不需要再回到主键索引上去取数据。
针对这个查询,我们可以创建一个 city、name 和 age 的联合索引,对应的 SQL 语句就是:
alter table t add index city_user_age(city, name, age);
这时,对于 city 字段的值相同的行来说,还是按照 name 字段的值递增排序的,此时的查询语句也就不再需要排序了。这样整个查询语句的执行流程就变成了:
(1). 从索引 (city,name,age) 找到第一个满足 city='杭州’条件的记录,取出其中的 city、name 和 age 这三个字段的值,作为结果集的一部分直接返回;
(2). 从索引 (city,name,age) 取下一个记录,同样取出这三个字段的值,作为结果集的一部分直接返回;重复执行步骤 2,直到查到第 1000 条记录,或者是不满足 city='杭州’条件时循环结束。
Extra 字段里面多了“Using index”,表示的就是使用了覆盖索引,性能上会快很多。
假设你的表里面已经有了 city_name(city, name) 这个联合索引,然后你要查杭州和苏州两个城市中所有的市民的姓名,并且按名字排序,显示前 100 条记录。如果 SQL 查询语句是这么写的 :
mysql> select * from t where city in ('杭州',"苏州") order by name limit 100;
如何实现一个在数据库端不需要排序的方案:
这里,我们要用到 (city,name) 联合索引的特性,把这一条语句拆成两条语句,执行流程如下:
(1). 执行 select * from t where city=“杭州” order by name limit 100; 这个语句是不需要排序的,客户端用一个长度为 100 的内存数组 A 保存结果。
(2). 执行 select * from t where city=“苏州” order by name limit 100; 用相同的方法,假设结果被存进了内存数组 B。
(3). 现在 A 和 B 是两个有序数组,然后你可以用归并排序的思想,得到 name 最小的前 100 值,就是我们需要的结果了。
5. 显示随机消息 - 内存临时表
有一个含有1000行的单词表,要随机选择 3 个单词,建表语句如下:
mysql> CREATE TABLE `words` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`word` varchar(64) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB;
实现语句:
mysql> select word from words order by rand() limit 3;
Extra 字段显示 Using temporary,表示的是需要使用临时表;Using filesort,表示的是需要执行排序操作。因此这个 Extra 的意思就是,需要临时表,并且需要在临时表上排序。
对于 InnoDB 表来说,执行全字段排序会减少磁盘访问,因此会被优先选择。对于内存表,回表过程只是简单地根据数据行的位置,直接访问内存得到数据,根本不会导致多访问磁盘。优化器没有了这一层顾虑,那么它会优先考虑的,就是用于排序的行越小越好了,所以,MySQL 这时就会选择 rowid 排序。
这条语句的执行流程是这样的:
-
创建一个临时表。这个临时表使用的是 memory 引擎,表里有两个字段,第一个字段是 double 类型,为了后面描述方便,记为字段 R,第二个字段是 varchar(64) 类型,记为字段 W。并且,这个表没有建索引。
-
从 words 表中,按主键顺序取出所有的 word 值。对于每一个 word 值,调用 rand() 函数生成一个大于 0 小于 1 的随机小数,并把这个随机小数和 word 分别存入临时表的 R 和 W 字段中,到此,扫描行数是 10000。
-
现在临时表有 10000 行数据了,接下来你要在这个没有索引的内存临时表上,按照字段 R 排序。
-
初始化 sort_buffer。sort_buffer 中有两个字段,一个是 double 类型,另一个是整型。
-
从内存临时表中一行一行地取出 R 值和位置信息,分别存入 sort_buffer 中的两个字段里。这个过程要对内存临时表做全表扫描,此时扫描行数增加 10000,变成了 20000。
-
在 sort_buffer 中根据 R 的值进行排序。注意,这个过程没有涉及到表操作,所以不会增加扫描行数。
-
排序完成后,取出前三个结果的位置信息,依次到内存临时表中取出 word 值,返回给客户端。这个过程中,访问了表的三行数据,总扫描行数变成了 20003。
图中的 pos 就是位置信息,如果你创建的表没有主键,或者把一个表的主键删掉了,那么 InnoDB 会自己生成一个长度为 6 字节的 rowid 来作为主键。这也就是排序模式里面,rowid 名字的来历。实际上它表示的是:每个引擎用来唯一标识数据行的信息。
对于有主键的 InnoDB 表来说,这个 rowid 就是主键 ID;
对于没有主键的 InnoDB 表来说,这个 rowid 就是由系统生成的;
总结:order by rand() 使用了内存临时表,内存临时表排序的时候使用了 rowid 排序方法。
6. 显示随机消息 - 磁盘临时表
那么,是不是所有的临时表都是内存表呢?
tmp_table_size 这个配置限制了内存临时表的大小,默认值是 16M。如果临时表大小超过了 tmp_table_size,那么内存临时表就会转成磁盘临时表。
当使用磁盘临时表的时候,对应的就是一个没有显式索引的 InnoDB 表的排序过程。
MySQL 5.6 版本引入的一个新的排序算法,即:优先队列排序算法。使用优先队列排序算法(维护一个包含3个元素的大顶堆,遍历,小的话替换堆顶),这个过程不需要临时文件,因此对应的number_of_tmp_files 是 0。sort buffer代表排序内存的大小,这个大顶堆是占用sort buffer(排序内存)的。
7. 随机排序方法
(1). 取得整个表的行数,并记为 C。
(2). 取得 Y = floor(C * rand())。 floor 函数在这里的作用,就是取整数部分。
(3). 再用 limit Y,1 取得一行。
MySQL 处理 limit Y,1 的做法就是按顺序一个一个地读出来,丢掉前 Y 个,然后把下一个记录作为返回结果,因此这一步需要扫描 Y+1 行。再加上,第一步扫描的 C 行,总共需要扫描 C+Y+1 行。
随机取 3 个 word 值:
mysql> select count(*) into @C from t;
set @Y1 = floor(@C * rand());
set @Y2 = floor(@C * rand());
set @Y3 = floor(@C * rand());
select * from t limit @Y1,1; //在应用代码里面取Y1、Y2、Y3值,拼出SQL后执行
select * from t limit @Y2,1;
select * from t limit @Y3,1;
8. 汇总
【Using filesort】本次查询语句中有order by,且排序依照的字段不在本次使用的索引中,不能自然有序。需要进行额外的排序工作。 【Using index】使用了覆盖索引——即本次查询所需的所有信息字段都可以从利用的索引上取得。无需回表,额外去主索引上去数据。 【Using index condition】使用了索引下推技术ICP。(虽然本次查询所需的数据,不能从利用的索引上完全取得,还是需要回表去主索引获取。但在回表前,充分利用索引中的字段,根据where条件进行过滤。提前排除了不符合查询条件的列。这样就减少了回表的次数,提高了效率。) 【Using where】表示本次查询要进行筛选过滤。 【Using temporary】表示的是需要使用临时表。