四种:1.主键 2.单值 3.唯一 4.复合
mysql5.6以后优化器做了很多改进,执行时会自动进行大量的优化,很多现象需要在5.5才能演示成功。
模拟优化器查看执行计划
使用EXPLAIN关键字可以模拟优化器执行SQL查询语句,从而知道MySQL是如何处理你的SQL语句的。分析你的查询语句或是表结构的性能瓶颈
表的读取顺序
那些索引可以使用
数据读取操作的操作类型
那些索引被实际使用
表之间的引用
每张表有多少行被物理查询
explain + SQL语句
官方文档:MySQL :: MySQL 8.0 Reference Manual :: 8.8.2 EXPLAIN Output Format
数据准备:
CREATE TABLE t1(id INT(10) AUTO_INCREMENT, content VARCHAR(100) NULL, PRIMARY KEY (id));
CREATE TABLE t2(id INT(10) AUTO_INCREMENT, content VARCHAR(100) NULL, PRIMARY KEY (id));
CREATE TABLE t3(id INT(10) AUTO_INCREMENT, content VARCHAR(100) NULL, PRIMARY KEY (id));
CREATE TABLE t4(id INT(10) AUTO_INCREMENT, content VARCHAR(100) NULL, PRIMARY KEY (id));
# 以下新增sql多执行几次,以便演示
INSERT INTO t1(content) VALUES(CONCAT('t1_',FLOOR(1+RAND()*1000)));
INSERT INTO t2(content) VALUES(CONCAT('t2_',FLOOR(1+RAND()*1000)));
INSERT INTO t3(content) VALUES(CONCAT('t3_',FLOOR(1+RAND()*1000)));
INSERT INTO t4(content) VALUES(CONCAT('t4_',FLOOR(1+RAND()*1000)));
演示:explain select * from t1, t2, t3 where t1.id=t2.id and t2.id=t3.id;
select查询的序列号,表示查询中执行select子句或操作表的顺序
三种情况:
① id相同,执行顺序由上至下。例如上图
② id不同,如果是子查询,id的序号会递增,id值越大优先级越高,越先被执行
EXPLAIN SELECT *
FROM t1 WHERE t1.content =(
SELECT t2.content
FROM t2 WHERE t2.content=(
SELECT t3.content
FROM t3
WHERE t3.content=""
)
);
id为NULL最后执行。
关注点:每个id号码,表示一趟独立的查询。一个sql 的查询趟数越少越好。
查询的类型,主要是用于区别普通查询、联合查询、子查询等的复杂查询
|
简单的 SELECT(没有 使用UNION或者 子查询(PS:单表查询)) |
---|---|
|
最外层的Select 作为primary 查询。(PS:含有子查询的情况,但是并不复杂)案例1 |
|
在from 查询语句中的(派生,嵌套很多)子查询.(PS:递归操作这些子查询) |
|
在SELECT或WHERE列表中包含了子查询。案例2 |
|
第一个查询是子查询,依赖于外部查询(相关查询)。案例3 |
|
在非相关子查询中 并且需要进行物化时会出现MATERIALIZED关键词。案例4 |
|
子查询结果(系统变量)不能被缓存, 而且必须重写(分析)外部查询的每一行。案例5 |
|
若第二个SELECT出现在UNION之后,则被标记为UNION。案例6 若UNION包含在FROM子句的子查询中,外层SELECT将被标记为:DERIVED |
|
结果集是通过union 而来的。案例6 |
案例1:explain select * from (select t2.* from t2) s2
案例2:explain select * from t1 where t1.id=(select t2.id from t2 where t2.id=1)
案例3:explain select t1.*,(select t2.content from t2 where t2.id=t1.id) from t1 where t1.id=1;
案例4:explain select * from t1 where t1.content in (select t2.content from t2 where t2.content in (select t3.content from t3 where t3.content='')) #需要5.7以后版本演示
案例5:EXPLAIN SELECT * from t1 where t1.id=(select t2.id from t2 where t2.id=@@sort_buffer_size);
案例6:explain select * from t1 UNION select * from t2;
显示这一行的数据是关于哪张表的
代表分区表中的命中情况,非分区表,该项为null
type显示的是访问类型,是较为重要的一个指标,结果值从最好到最坏依次是:
null>system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
常见:system > const > eq_ref > ref > range > index > ALL
一般来说,得保证查询至少达到range级别,最好能达到ref。
null: MySQL不访问任何表或索引,直接返回结果
system:表只有一行记录(等于系统表),这是const类型的特列,平时不会出现,这个也可以忽略不计。
const:表示通过索引一次就找到了,const用于比较primary key或者unique索引。因为只匹配一行数据,所以很快。如将主键置于where列表中,MySQL就能将该查询转换为一个常量。(select * from t1 where t1.id=1)
eq_ref:唯一性索引扫描,对于每个索引键,表中只有一条记录与之匹配。常见于主键或唯一索引扫描。(select * from t1,t2 where t1.id=t2.id)
ref: 使用非唯一索引扫描或唯一索引前缀扫描,返回单条记录,常出现在关联查询中
range:只检索给定范围的行,使用一个索引来选择行。key 列显示使用了哪个索引,一般就是在你的where语句中出现了between、<、>、in等的查询。这种范围扫描索引扫描比全表扫描要好,因为它只需要开始于索引的某一点,而结束语另一点,不用扫描全部索引。(select * from t1 where t1.id<10)
index:出现index是sql使用了索引但是没用通过索引进行过滤,一般是使用了覆盖索引或者是利用索引进行了排序分组。(explain select id from t1)
all:Full Table Scan,将遍历全表以找到匹配的行。(explain select * from t1)
index_merge:在查询过程中需要多个索引组合使用,通常出现在有 or 的关键字的sql中。
ref_or_null:对于某个字段既需要关联条件,也需要null值得情况下。查询优化器会选择用ref_or_null连接查询。
index_subquery:利用索引来关联子查询,不再全表扫描。
unique_subquery:该联接类型类似于index_subquery。 子查询中的唯一索引。
① 创建索引
② index_merge
EXPLAIN SELECT * FROM t3 WHERE t3.content IS NULL OR t3.id=10;
③ ref_or_null
EXPLAIN SELECT * FROM t3 WHERE t3.content IS NULL OR t3.content='aaaa';
④ index_subquery
EXPLAIN SELECT * FROM t2 WHERE t2.content IN (SELECT t3.content FROM t3);
⑤ unique_subquery
EXPLAIN SELECT * FROM t2 WHERE t2.id IN (SELECT t3.id FROM t3);
显示可能应用在这张表中的索引,一个或多个。
查询涉及到的字段上若存在索引,则该索引将被列出,但不一定被查询实际使用。
实际使用的索引。如果为NULL,则没有使用索引。
查询中若使用了覆盖索引,则该索引和查询的select字段重叠。
表示索引中使用的字节数,可通过该列计算查询中使用的索引的长度。
key_len字段能够帮你检查是否充分的利用上了索引。
如何计算
① 先看索引上字段的类型+长度比如 int=4 ; varchar(20) =20 ; char(20) =20
② 如果是varchar或者char这种字符串字段,视字符集要乘不同的值,比如utf8mb3要乘 3(MySQL5.7),如果是utf8mb4要乘4,,GBK要乘2
③ varchar这种动态字符串要加2个字节
④ 允许为空的字段要加1个字节
索引字段最好不要为NULL,因为NULL让统计更加复杂,并且需要额外一个字节的存储空间。
显示索引的哪一列被使用了,如果可能的话,是一个常数。哪些列或常量被用于查找索引列上的值。
rows列显示MySQL认为它执行查询时必须检查的行数。越少越好。
这个字段表示存储引擎返回的数据在server层过滤后,剩下多少满足查询的记录数量的比例,注意是百分比,不是具体记录数,
值越大越好
。
包含不适合在其他列中显示但十分重要的额外信息,通过这些额外信息来理解MySQL到底将如何执行当前的查询语句
。MySQL提供的额外信息有好几十个,这里只挑比较重要的介绍。
Using filesort:说明mysql会对数据使用一个外部的索引排序,而不是按照表内的索引顺序进行读取。
MySQL中无法利用索引完成的排序操作称为“文件排序”
这类SQL语句性能极差,需要进行优化。
在一个非索引列上进行了order by,就会触发filesort,常见的优化方案是,在order by的列上添加索引,避免每次查询都全量排序(只查询索引列的值)。
Using temporary:使了用临时表保存中间结果,MySQL在对查询结果排序时使用临时表。常见于排序 order by 和分组查询 group by。
group by和order by同时存在,且作用于不同的字段时,就会建立临时表,以便计算出最终的结果集。
USING index:利用索引进行了排序或分组。表示相应的select操作中使用了覆盖索引(Covering Index),避免访问了表的数据行,效率不错!(EXPLAIN select * from t_emp where age=30 ORDER BY name)如果同时出现using where,表明索引被用来执行索引键值的查找;如果没有同时出现using where,表明索引只是用来读取数据而非利用索引执行查找。
Using where:表明使用了where过滤
using join buffer:使用了连接缓存,非主键关联(mysql8Using join buffer (hash join)
速度要好于 mysql5.7Using join buffer (Block Nested Loop)
)
impossible where:where子句的值总是false,不能用来获取任何元组。(EXPLAIN select * from t_emp where false;)
select tables optimized away:在没有GROUPBY子句的情况下,基于索引优化MIN/MAX操作或者对于MyISAM存储引擎优化COUNT(*)操作,不必等到执行阶段再进行计算,查询执行计划生成的阶段即完成优化。
在innodb中:
在Myisam中:
表的读取顺序:id
id趟数越少越好,id相同执行顺序由上至下,id不同 大的先执行
查询方式:select_type
那些索引可以使用:possible_keys
数据读取操作的操作类型:type
range index all
那些索引被实际使用:key
创建的索引是否能够被实际应用
使用索引的长度:key_len
命中的索引匹配的长度(用来判断索引是否被完全利用)
计算索引长度:
utf-8
varchar(len) =使用len*3+2 (如果字段可以为null,再+1)
char(len) =使用len*3 (如果字段可以为null,再+1)
int(len) = 4 (如果字段可以为null,再+1)
表之间的引用:table
每张表有多少行被物理查询:rows
行数越少越好(多表联查时 被驱动表的rows如果使用索引了一般非常小)
额外优化信息:extra
using join buffer(多表联查)、using filesort(排序)和 using temporary(分组) 需要考虑优化
其他情况性能都可以无需优化
EXPLAIN语句输出中缺少了一个衡量执行计划好坏的重要属性 —执行计划花费的成本,在EXPLAIN单词和真正的查询语句中间加上FORMAT=JSON。
EXPLAIN FORMAT=json SELECT * FROM t_emp;
{
"query_block": {
"select_id": 1,
"cost_info": {
"query_cost": "1.25" // 查询耗时:单位毫秒
},
"table": {
"table_name": "t_emp",
"access_type": "ALL",
"rows_examined_per_scan": 10,
"rows_produced_per_join": 10,
"filtered": "100.00",
"cost_info": {
"read_cost": "0.25",//io耗时
"eval_cost": "1.00",//获取处理返回结果耗时
"prefix_cost": "1.25",
"data_read_per_join": "800"//读取的数据量
},
"used_columns": [//投影列
"id",
"name",
"age",
"deptId",
"empno"
]
}
}
}
在做优化之前,要准备大量数据。接下来创建两张表,并往员工表里插入50W数据,部门表中插入1W条数据。
建表sql:
CREATE TABLE `dept` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`deptName` VARCHAR(30) DEFAULT NULL,
`address` VARCHAR(40) DEFAULT NULL,
ceo INT NULL ,
PRIMARY KEY (`id`)
) ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
CREATE TABLE `emp` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`empno` INT NOT NULL ,
`name` VARCHAR(20) DEFAULT NULL,
`age` INT(3) DEFAULT NULL,
`deptId` INT(11) DEFAULT NULL,
PRIMARY KEY (`id`)
#CONSTRAINT `fk_dept_id` FOREIGN KEY (`deptId`) REFERENCES `t_dept` (`id`)
) ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
怎么快速插入50w条数据呢? 存储过程
怎么保证插入的数据不重复?函数
以部门表分析:
id:自增长
deptName:随机字符串,允许重复
address:随机字符串,允许重复
CEO:1-50w之间的任意数字
以员工表分析:
id:自增长
empno:可以使用随机数字,或者从1开始的自增数字,不允许重复
name:随机生成,允许姓名重复
age:区间随机数
deptId:1-1w之间随机数
总结:需要产生随机字符串和区间随机数的函数。
set global log_bin_trust_function_creators=1;
# 随机产生字符串
DELIMITER $$
CREATE FUNCTION rand_string(n INT) RETURNS VARCHAR(255)
BEGIN
DECLARE chars_str VARCHAR(100) DEFAULT 'abcdefghijklmnopqrstuvwxyzABCDEFJHIJKLMNOPQRSTUVWXYZ';
DECLARE return_str VARCHAR(255) DEFAULT '';
DECLARE i INT DEFAULT 0;
WHILE i < n DO
SET return_str =CONCAT(return_str,SUBSTRING(chars_str,FLOOR(1+RAND()*52),1));
SET i = i + 1;
END WHILE;
RETURN return_str;
END $$
#用于随机产生区间数字
DELIMITER $$
CREATE FUNCTION rand_num (from_num INT ,to_num INT) RETURNS INT(11)
BEGIN
DECLARE i INT DEFAULT 0;
SET i = FLOOR(from_num +RAND()*(to_num -from_num+1));
RETURN i;
END$$
#假如要删除
#drop function rand_string;
#drop function rand_num;
# 插入员工存储过程
DELIMITER $$
CREATE PROCEDURE insert_emp(START INT, max_num INT)
BEGIN
DECLARE i INT DEFAULT 0;
#set autocommit =0 把autocommit设置成0
SET autocommit = 0;
REPEAT
SET i = i + 1;
INSERT INTO emp (empno, NAME, age, deptid ) VALUES ((START+i) ,rand_string(6), rand_num(30,50), rand_num(1,10000));
UNTIL i = max_num
END REPEAT;
COMMIT;
END$$
#删除
# DELIMITER ;
# drop PROCEDURE insert_emp;
#往dept表添加随机数据
DELIMITER $$
CREATE PROCEDURE `insert_dept`(max_num INT)
BEGIN
DECLARE i INT DEFAULT 0;
SET autocommit = 0;
REPEAT
SET i = i + 1;
INSERT INTO dept ( deptname,address,ceo ) VALUES (rand_string(8),rand_string(10),rand_num(1,500000));
UNTIL i = max_num
END REPEAT;
COMMIT;
END$$
#删除
# DELIMITER ;
# drop PROCEDURE insert_dept;
#执行存储过程,往dept表添加1万条数据
DELIMITER ;
CALL insert_dept(10000);
#执行存储过程,往emp表添加50万条数据
DELIMITER ;
CALL insert_emp(100000,500000);
批量删除某个表上的所有索引
DELIMITER $$
CREATE PROCEDURE `proc_drop_index`(dbname VARCHAR(200),tablename VARCHAR(200))
BEGIN
DECLARE done INT DEFAULT 0;
DECLARE ct INT DEFAULT 0;
DECLARE _index VARCHAR(200) DEFAULT '';
DECLARE _cur CURSOR FOR SELECT index_name FROM information_schema.STATISTICS WHERE table_schema=dbname AND table_name=tablename AND seq_in_index=1 AND index_name <>'PRIMARY' ;
DECLARE CONTINUE HANDLER FOR NOT FOUND set done=2 ;
OPEN _cur;
FETCH _cur INTO _index;
WHILE _index<>'' DO
SET @str = CONCAT("drop index ",_index," on ",tablename );
PREPARE sql_str FROM @str ;
EXECUTE sql_str;
DEALLOCATE PREPARE sql_str;
SET _index='';
FETCH _cur INTO _index;
END WHILE;
CLOSE _cur;
END$$
执行批量删除:
CALL proc_drop_index("dbname","tablename"); # 库名称和表名称
不在索引列上做任何操作(计算、函数、(自动or手动)类型转换),会导致索引失效而转向全表扫描
like以通配符开头('%abc...')mysql索引失效会变成全表扫描的操作
mysql 在使用不等于(!=或者<>)的时候无法使用索引会导致全表扫描
is not null 也无法使用索引,但是is null是可以使用索引的
字符串不加单引号索引失效
案例:
查找姓名以"abc"开头的员工信息
查找姓名含有"abc"的员工信息
查找年龄不等于25的员工
查找姓名不为空的员工信息
查找姓名等于"123"的员工信息
# 创建索引
create index idx_emp_age on emp(age);
create index idx_emp_name on emp(name);
EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE emp.name LIKE 'abc%';
EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE LEFT(emp.name,3)='abc';
sql访问类型range > ALL;使用索引idx_emp_name > NULL; 使用索引长度63 > NULL; 扫描行数25 < 498951
第一个sql用时:0.00s
第二个sql用时:0.37s
由此可见第一个sql优于第二个sql:第一个走了索引,第二个走了全表扫描。
可以发现改成'%abc%'之后,第一个sql失去了索引优势,走了全表扫描。
EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE emp.age=30;
EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE emp.age!=30;
全值匹配我最爱
符合最左原则:不跳过索引中的列。
如果where条件中是OR关系,加索引不起作用
存储引擎不能使用索引中范围条件右边的列
① 首先删除之前创建的索引
CALL proc_drop_index("mydb","emp");
② 全值匹配我最爱
SELECT SQL_NO_CACHE * FROM emp WHERE age=30 and deptId=1 and name='abc';
create index idx_age_deptId_name on emp(age, deptId, name);
SELECT SQL_NO_CACHE * FROM emp WHERE age=30 and deptId=1 and name='abc';
③最左匹配原则
④ OR关联
⑤ 范围条件右边的列
一般性建议:
对于单键索引,尽量选择针对当前query过滤性更好的索引
在选择组合索引的时候,当前Query中过滤性最好的字段在索引字段顺序中,位置越靠前越好。
在选择组合索引的时候,尽量选择可以能够包含当前query中的where字句中更多字段的索引
在选择组合索引的时候,如果某个字段可能出现范围查询时,尽量把这个字段放在索引次序的最后面
书写sql语句时,尽量避免造成索引失效的情况
假设index(a,b,c) 重要
Where语句 | 索引是否被使用 |
---|---|
where a = 3 | Y,使用到a |
where a = 3 and b = 5 | Y,使用到a,b |
where a = 3 and b = 5 and c = 4 | Y,使用到a,b,c |
where b = 3 或者 where b = 3 and c = 4 或者 where c = 4 | N |
where a = 3 and c = 5 | 使用到a, 但是c不可以,b中间断了 |
where a = 3 and b > 4 and c = 5 | 使用到a和b, c不能用在范围之后,b断了 |
where a is null and b is not null | is null 支持索引 is not null 类似范围查询,ab能使用,b右边的会失效 |
where a <> 3 | 不能使用索引 |
where abs(a) =3 | 不能使用 索引 |
where a = 3 and b like 'kk%' and c = 4 | Y,使用到a,b,c |
where a = 3 and b like '%kk' and c = 4 | Y,只用到a |
where a = 3 and b like '%kk%' and c = 4 | Y,只用到a |
where a = 3 and b like 'k%kk%' and c = 4 | Y,使用到a,b,c |
4. 关联查询优化
接下来再次创建两张表,并分别导入20条数据:
CREATE TABLE IF NOT EXISTS `class` (
`id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
`card` INT(10) UNSIGNED NOT NULL,
PRIMARY KEY (`id`)
);
CREATE TABLE IF NOT EXISTS `book` (
`bookid` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
`card` INT(10) UNSIGNED NOT NULL,
PRIMARY KEY (`bookid`)
);
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
explain分析一下两个sql:
EXPLAIN SELECT * FROM class LEFT JOIN book ON class.card = book.card;
EXPLAIN SELECT * FROM class RIGHT JOIN book ON class.card = book.card;
EXPLAIN SELECT * FROM class INNER JOIN book ON class.card = book.card;
给book.card创建索引:
ALTER TABLE `book` ADD INDEX idx_card ( `card`);
然后explain分析:
删除旧索引,添加新索引:
# 删除旧索引 + 新建 + 第3次explain
drop index idx_card on book;
ALTER TABLE class ADD INDEX index_class_card (card);
再次explain分析:
同时给两张表的card字段添加索引:(class(card)索引已有:index_class_card,只需给book(card)添加索引)
ALTER TABLE `book` ADD INDEX idx_card ( `card`);
最后explain分析:
保证被驱动表的join字段已经创建了索引
left/right join 时,选择小表作为驱动表,大表作为被驱动表。
inner join 时,mysql会自己帮你把小结果集的表选为驱动表,对被驱动表连接字段创建索引。(5.6已经优化掉了,5.5需要手动编写)
子查询尽量不要放在被驱动表,有可能使用不到索引。
能够直接多表关联的尽量直接关联,不用子查询。(减少查询的趟数)
尽量不要使用not in 或者 not exists
尽量不要使用子查询
以下三种情况不走索引:
无过滤,不索引
顺序错,不索引
方向反,不索引
create index idx_age_deptid_name on emp (age,deptid,name)
# 以下 是否能使用到索引,能否去掉using filesort
explain select SQL_NO_CACHE * from emp order by age,deptid;
explain select SQL_NO_CACHE * from emp order by age,deptid limit 10;
# 无过滤 不索引 观察extra的值
explain select * from emp where age=45 order by deptid;
explain select * from emp where age=45 order by deptid,name;
explain select * from emp where age=45 order by deptid,empno;
explain select * from emp where age=45 order by name,deptid;
explain select * from emp where deptid=45 order by age;
# 顺序错,不索引
explain select * from emp where age=45 order by deptid desc, name desc ;
# 方向反 不索引
explain select * from emp where age=45 order by deptid asc, name desc ;
ORDER BY子句,尽量使用Index方式排序,避免使用FileSort方式排序
执行案例前先清除emp上的索引,只留主键
# 查询 年龄为30岁的,且员工编号小于101000的用户,按用户名称排序
SELECT SQL_NO_CACHE * FROM emp WHERE age =30 AND empno <101000 ORDER BY NAME;
结论:很显然,执行时间为0.477s,type 是 ALL,即最坏的情况。Extra 里还出现了 Using filesort,也是最坏的情况。优化是必须的。
优化思路: 尽量让where的过滤条件和排序使用上索引。
现在过滤条件使用了两个字段(age,empno)排序使用了name。
我们建一个三个字段的组合索引可否?
CREATE INDEX idx_age_empno_name ON emp(age,empno,NAME);
再次explain测试:
我们发现using filesort 依然存在,所以name 并没有用到索引。
原因是因为empno是一个范围过滤,所以索引后面的字段不会再使用索引了。
所以我们建一个3值索引是没有意义的 那么我们先删掉这个索引:DROP INDEX idx_age_empno_name ON emp
为了去掉filesort我们可以把索引建成
CREATE INDEX idx_age_name ON emp(age,NAME);
也就是说empno 和name这个两个字段只能二选其一。 这样我们优化掉了 using filesort。
执行一下sql:
速度果然提高了4倍。
假如:选择创建age和empno会速度会怎样呢,自己试试有惊喜!
结果竟然有 filesort的 sql 运行速度,超过了已经优化掉 filesort的 sql ,而且快了好多倍。何故?
原因:是所有的排序都是在条件过滤之后才执行的,所以如果条件过滤了大部分数据的话,几百几千条数据进行排序其实并不是很消耗性能,即使索引优化了排序但实际提升性能很有限。 相对的 empno<101000 这个条件如果没有用到索引的话,要对几万条的数据进行扫描,这是非常消耗性能的,所以索引放在这个字段上性价比最高,是最优选择。
结论: 当范围条件和group by 或者 order by 的字段出现二选一时 ,优先观察条件字段的过滤数量,如果过滤的数据足够多,而需要排序的数据并不多时,优先把索引放在范围字段上。反之,亦然。
如果不在索引列上,filesort有两种算法:mysql就要启动双路排序和单路排序
MySQL 4.1之前是使用双路排序,字面意思就是两次扫描磁盘,最终得到数据,读取行指针和orderby列,对他们进行排序,然后扫描已经排序好的列表,按照列表中的值重新从列表中读取对应的数据输出。
也就是:从磁盘取排序字段,再buffer进行排序,再从磁盘取其他字段。
取一批数据,要对磁盘进行了两次扫描,众所周知,I\O是很耗时的,所以在mysql4.1之后,出现了第二种改进的算法,就是单路排序。
从磁盘读取查询需要的所有列,按照order by列在buffer对它们进行排序,然后扫描排序后的列表进行输出,它的效率更快一些,避免了第二次读取数据。并且把随机IO变成了顺序IO,但是它会使用更多的空间,因为它把每一行都保存在内存中了。
结论及引申出的问题:由于单路是后出的,总体而言好过双路。
但是用单路有问题:在sort_buffer中,比双路排序要多占用很多空间,因为单路排序是把所有字段都取出, 所以有可能取出的数据的总大小超出了sort_buffer的容量,导致每次只能取sort_buffer容量大小的数据,进行排序(创建tmp文件,多路合并),排完再取取sort_buffer容量大小,再排……从而多次I/O。
本来想省一次I/O操作,反而导致了大量的I/O操作,反而得不偿失。
Order by时select * 是一个大忌,只Query需要的字段, 这点非常重要。在这里的影响是
当Query的字段大小总和小于max_length_for_sort_data 而且排序字段不是 TEXT|BLOB 类型时,会用改进后的算法——单路排序, 否则用老算法——多路排序。
两种算法的数据都有可能超出sort_buffer的容量,超出之后,会创建tmp文件进行合并排序,导致多次I/O,但是用单路排序算法的风险会更大一些,所以要提高sort_buffer_size。
尝试提高 sort_buffer_size
不管用哪种算法,提高这个参数都会提高效率,当然,要根据系统的能力去提高,因为这个参数是针对每个进程的 1M-8M之间调整
尝试提高 max_length_for_sort_data
提高这个参数, 会增加用改进算法的概率。但是如果设的太高,数据总容量超出sort_buffer_size的概率就增大,明显症状是高的磁盘I/O活动和低的处理器使用率。1024-8192之间调整
group by 使用索引的原则几乎跟order by一致 ,唯一区别是groupby 即使没有过滤条件用到索引,也可以直接使用索引。
group by 先排序再分组,遵照索引建的最佳左前缀法则
当无法使用索引列,增大max_length_for_sort_data和sort_buffer_size参数的设置
where高于having, 能写在where限定的条件就不要写在having中了
只要对分组列创建索引即可
最后使用索引的手段:覆盖索引
什么是覆盖索引?简单说就是,select 到 from 之间查询的列 <=使用的索引列+主键
explain select * from emp where name like '%abc';
使用覆盖索引后
理解方式一:索引是高效找到行的一个方法,但是一般数据库也能使用索引找到一个列的数据,因此它不必读取整个行。毕竟索引叶子节点存储了它们索引的数据;当能通过读取索引就可以得到想要的数据,那就不需要读取行了。==一个索引包含了满足查询结果的数据就叫做覆盖索引==
理解方式二:非聚集复合索引的一种形式,它包括在查询里的Select、Join和Where子句用到的所有列(即建索引的字段正好是覆盖查询条件中所涉及的字段,也即,索引包含了查询正在查找的数据)。
9. 索引无效说明
创建索引后,用不用索引,最终是优化器说了算。
优化器会基于开销选择索引
,怎么开销小就怎么来。不是基于规则,也不是基于语义。
另外SQL语句是否使用索引,和数据库的版本、数据量、数据选择度(查询中选择的列数)运行环境都有关系。
所有创建索引后需要结合explain进行分析索引是否有效