点击上方蓝字关注我们 文末有惊喜
初始化SQL
CREATE TABLE `student` (
`id` INT ( 11 ) NOT NULL AUTO_INCREMENT,
`stu_name` VARCHAR ( 24 ) NOT NULL DEFAULT '' COMMENT '学生姓名',
`stu_age` INT ( 11 ) NOT NULL DEFAULT '0' COMMENT '学生年龄',
`stu_addr` VARCHAR ( 20 ) NOT NULL DEFAULT '' COMMENT '地址',
`birthday` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '出生日期',
PRIMARY KEY ( `id` ),
KEY `idx_name_age_addr` ( `stu_name`, `stu_age`, `stu_addr` ) USING BTREE
) ENGINE = INNODB AUTO_INCREMENT = 4 DEFAULT CHARSET = utf8 COMMENT = '学生档案表';
INSERT INTO student ( stu_name, stu_age, stu_addr, birthday )
VALUES
(
'刘备',
100,
'三国蜀',
NOW());
INSERT INTO student ( stu_name, stu_age, stu_addr, birthday )
VALUES
(
'张飞',
110,
'三国蜀',
NOW());
INSERT INTO student ( stu_name, stu_age, stu_addr, birthday )
VALUES
(
'关羽',
90,
'三国蜀',
NOW());
表描述:创建了一个联合索引和一个主键索引
EXPLAIN SELECT * FROM student WHERE stu_name= '关羽';
在这里插入图片描述
查看索引长度是74=(3*24+2),可以算出联合索引中只使用了name前缀索引.
EXPLAIN SELECT * FROM student WHERE stu_name= '关羽' and stu_age = 20;
查看索引长度是78=(3*24+2)+4,可以算出联合索引中只使用了stu_name和stu_age前缀索引.
EXPLAIN SELECT * FROM student WHERE stu_name= '关羽' and stu_age = 20 and stu_addr = '三国蜀'
查看索引长度是140=(324+2)+4+(320+2),可以算出联合索引中只使用了完整的联合索引
EXPLAIN SELECT * FROM student WHERE stu_name= '关羽'
可以看出使用到了前缀索引。
EXPLAIN SELECT * FROM student WHERE stu_age= 20;
key_len为空,说明没有使用索引,因为违背了最左前缀规则,跳过了name,直接使用age,mysql就直接使用全表扫描了。
EXPLAIN SELECT * FROM student WHERE stu_age= 20 and stu_name = '刘备' and stu_addr ='三国';
在这里插入图片描述
看截图,mysql使用了联合索引,但是命名不遵循最左前缀原则啊,这是因为mysql5.7中。在执行器中,mysql会对sql语句进行优化,调整三个字段的顺序,满足最左前原则。
EXPLAIN SELECT * FROM student WHERE left(stu_name,2) = '张飞'
按照最左前缀法则,上面的语句应该会使用索引的,但是由于在索引字段上面使用了函数,导致索引失效,mysql在使用优化器的时候,发现索引字段上面使用了函数,将会放弃索引查找,因为它觉得全表扫描会更快。
在这里插入图片描述
explain select * from student where stu_name =1000
stu_name 发生了隐式类型转换,导致索引失效。
EXPLAIN SELECT * FROM student WHERE stu_name = '张飞' and stu_age > 100 and stu_addr = '吴国';
在这里插入图片描述
从索引长度上看,应该只走了name+age的联合索引,addr没用联合索引查询。
explain select stu_name from student where stu_name = '刘备'
explain select * from student where stu_name = '刘备'
在这里插入图片描述
第二条语句extra字段值为空,但是第一条是using index,说明使用了索引覆盖,第二条语句为空的原因是mysql在索引树上面查询到数据之后,还需要把去主键索引表中提取数据完整记录;而第一条定位到数据后,mysql看到select 里面的字段在索引内,所以就直接能拿到数据。
explain select * from student where stu_name != '刘备'
索引失效
explain select * from student where stu_name like '%备%'
在这里插入图片描述
因为我们开发过程中模糊查询肯定是必须的,那么怎么优化呢?
explain select stu_name from student where stu_name like '%备%'
其实在mysql底层,使用了一个trace
的工具,帮助你分析每条SQL语句,它会按照索引去查询语句,预估消耗的时间,然后再按照全表扫描,预估消耗的时间,最后比较两者消耗时间,选择是否走索引还是全表扫描,执行如下sql,查看结果2,分析trace字段的结果:
SET SESSION optimizer_trace = "enabled=on",
end_markers_in_json = ON;
SELECT
*
FROM
student
WHERE
stu_age > 10
ORDER BY
stu_age;
SELECT
*
FROM
information_schema.OPTIMIZER_TRACE;
预估表的访问成本
使用索引预估的访问成本
在这里插入图片描述
比较成本大小,则决定使用索引查询。
explain
SELECT
*
FROM
student
WHERE
stu_name = '刘备'
ORDER BY
stu_addr;
在这里插入图片描述
执行计划发现使用了文件排序 using filesort,原因是由于where 后面的语句过滤字段和排序字段中间跳过了age字段,索引排序是在文件中排序。
explain
SELECT
*
FROM
student
WHERE
stu_name = '刘备' and stu_age = 16
ORDER BY
stu_addr;
在这里插入图片描述
分析执行计划,发现using filesort没有了,因为满足了最左前缀原则了。加上了stu_age字段,直接可以在索引中完成排序。
explain
SELECT
*
FROM
student
WHERE
stu_name = '刘备'
ORDER BY
stu_addr,stu_age
在这里插入图片描述
执行计划中出现了filesort,原因是排序字段与索引建立的顺序不一致,不满足最左前缀法则,mysql没有使用索引进行排序。
explain
SELECT
*
FROM
student
WHERE
stu_name = '刘备'
ORDER BY
stu_age, stu_addr desc
分析执行计划,发现又出现了using filesort,使用了文件排序,按照排序确实按照最左前缀了啊,不应该啊。仔细观察发现。两个字段的排序方向不一致,这会导致索引无法进行排序,在索引树中:只能使用排序方向一致的索引,否则就需要使用文件排序了。
explain
SELECT
*
FROM
student
WHERE
stu_name in('刘备','张飞')
ORDER BY
stu_age
在这里插入图片描述
执行计划发现明明按照最左前缀的顺序查询和排序的,为什么又出现了文件排序呢?因为in查询属于范围查询,会导致右侧所有索引失效。
在上面优化中,发现在mysql中排序分为文件排序和索引排序,在无法使用索引排序的情况下,我们就得考虑如何优化文件排序了。文件排序分为两种:
我们可以使用上面提到的trace工具来分析:
SET SESSION optimizer_trace = "enabled=on",
end_markers_in_json = ON;
SELECT
*
FROM
student
WHERE
stu_name ='a'
ORDER BY
stu_addr,stu_age;
SELECT
*
FROM
information_schema.OPTIMIZER_TRACE;
{
"join_execution": {
"select#": 1,
"steps": [
{
"filesort_information": [
{
"direction": "asc",
"table": "`student`",
"field": "stu_addr"
},
{
"direction": "asc",
"table": "`student`",
"field": "stu_age"
}
] /* filesort_information */,
"filesort_priority_queue_optimization": {
"usable": false,
"cause": "not applicable (no LIMIT)"
} /* filesort_priority_queue_optimization */,
"filesort_execution": [
] /* filesort_execution */,
"filesort_summary": {
"rows": 0,
"examined_rows": 0,
"number_of_tmp_files": 0,
"sort_buffer_size": 204800 // sort buffer大小
"sort_mode": "<sort_key, packed_additional_fields>" // 单路排序
} /* filesort_summary */
}
] /* steps */
} /* join_execution */
}
分析trace结果中主要的字段:sort_buffer_size:204800 mysql设置的默认值为1m "sort_mode": "<sort_key, packed_additional_fields>" 单路排序 因为我们查询的字段长度肯定是小于1m的,我们现在设置下sort_buffer_size大小,然后再trace下结果:
// 修改默认值,记得测试完之后修改回默认值(1m)
set max_length_for_sort_data = 10;
再执行上面的语句,查看结果为:
"filesort_summary": {
"rows": 0,
"examined_rows": 0,
"number_of_tmp_files": 0,
"sort_buffer_size": 57344,
"sort_mode": "<sort_key, rowid>" // 双路排序 因为包含了rowid,需要根据rowid再去提取查询的字段。
} /* filesort_summary */
sort_mode 字段中包含了rowid,所以排序模式已经更改为双路排序了。// 设置回原来的值 set max_length_for_sort_data = 1024;
作者:乐哉
图片:来源于网络,如有侵权,联系删除。