一、插入数据
1.1、优化方案一(批量插入数据)
Insert into tb_test values(1,'Tom'),(2,'Cat'),(3,'Jerry');
1.2、优化方案二(手动控制事务)
start transaction;
insert into tb_test values(1,'Tom'),(2,'Cat'),(3,'Jerry');
insert into tb_test values(4,'Tom'),(5,'Cat'),(6,'Jerry');
insert into tb_test values(7,'Tom'),(8,'Cat'),(9,'Jerry');
commit;
1.3、优化方案三(主键顺序插入)
主键乱序插入 : 8 1 9 21 88 2 4 15 89 5 7 3
主键顺序插入 : 1 2 3 4 5 7 8 9 15 21 88 89
1.4、大批量插入数据
参考系列七的5.2章节
https://blog.csdn.net/HelloWorld20161112/article/details/129245692
二、主键优化
主键顺序插入的性能高于乱序插入的原因分析:
2.1、数据组织方式
行数据,都是存储在聚集索引的叶子节点上的。InnoDB的逻辑结构图:
在InnoDB存储引擎中,数据行是记录在逻辑结构 page 页中的,而每一个页的大小是固定的,默认16K。那也就意味着, 一个页中所存储的行也是有限的,如果插入的数据行row在该页存储不小,将会存储到下一个页中,页与页之间会通过指针连接。
2.2、页分裂
2.2.1、主键顺序插入
(1)从磁盘中申请页, 主键顺序插入
(2)第一个页没有满,继续往第一页插入
(3)当第一个也写满之后,再写入第二个页,页与页之间会通过指针连接
(4) 当第二页写满了,再往第三页写入
2.2.2、主键乱序插入
(1)假如1#,2#页都已经写满了,存放了如图所示的数据
(2)此时再插入id为50的记录,看看会发生什么现象?会再次开启一个页,写入新的页中吗?
不会。因为索引结构的叶子节点是有顺序的。按照顺序,应该存储在47之后。
但是47所在的1#页,已经写满了,存储不了50对应的数据了。 那么此时会开辟一个新的页 3#
但是并不会直接将50存入3#页,而是会将1#页后一半的数据,移动到3#页,然后在3#页,插入50。
上述的这种现象,称之为 "页分裂",是比较耗费性能的操作。
2.2.3、页合并
当我们对已有数据进行删除时,具体的效果如下:
当删除一行记录时,实际上记录并没有被物理删除,只是记录被标记(flaged)为删除并且它
的空间变得允许被其他记录声明使用。
当我们继续删除2#的数据记录:
这里面所发生的合并页的现象称之为 "页合并"。
说明:MERGE_THRESHOLD:合并页的阈值,可以自己设置,在创建表或者创建索引时指定。
2.2.4、索引设计原则
- 满足业务需求的情况下,尽量降低主键的长度;
-
插入数据时,尽量选择顺序插入,选择使用 AUTO_INCREMENT 自增主键;
- 尽量不要使用UUID做主键或者是其他自然主键,如身份证号;
- 业务操作时,避免对主键的修改;
三、order by优化
3.1、准备工作(索引初始化)
删除索引:idx_user_phone、idx_user_phone_name、idx_user_name
drop index idx_user_phone on tb_user;
drop index idx_user_phone_name on tb_user;
drop index idx_user_name on tb_user;
3.2、执行排序
3.2.1、排序的字段没有建立索引
explain select id,age,phone from tb_user order by age ;
explain select id,age,phone from tb_user order by age, phone ;
结果分析:由于 age, phone 都没有索引,所以排序时,出现Using filesort, 排序性能较低。
3.2.2、排序的字段建立了索引
# 创建索引
create index idx_user_age_phone on tb_user(age,phone);
结果分析:建立索引之后,再次进行排序查询,就由原来的Using filesort, 变为了 Using index,性能就比较高的了。
3.2.3、创建索引后,根据age, phone进行降序排序
结果分析:也出现 Using index, 但是此时Extra中出现了 Backward index scan,表示反向扫描索引,因为在MySQL中我们创建的索引,默认索引的叶子节点是从小到大排序的,而此时我们查询排序时,是从大到小,所以在扫描时,就是反向扫描,就会出现 Backward index scan。 在 MySQL8版本中,支持降序索引,我们也可以创建降序索引。
3.2.4、根据phone,age进行升序排序,phone在前,age在后
结果分析:排序时,也需要满足最左前缀法则,否则也会出现 filesort。因为在创建索引的时候, age是第一个字段,phone是第二个字段,所以排序时,也就该按照这个顺序来,否则就会出现 Using filesort。
3.2.5、根据age, phone进行排序,一个升序,一个降序
explain select id,age,phone from tb_user order by age asc , phone desc;
结果分析:因为创建索引时,如果未指定顺序,默认都是按照升序排序的,而查询时,一个升序,一个降序,此时就会出现Using filesort。
3.2.6、创建联合索引(age升序,phone降序)后再次执行上述SQL
create index idx_user_age_phone_ad on tb_user(age asc ,phone desc);
3.2.7、升序/降序联合结构示意图
3.2.8、order by优化总结
(1)根据排序字段建立合适的索引,多字段排序时,也遵循最左前缀法则;
(2)尽量使用覆盖索引;
(3)多字段排序, 一个升序一个降序,此时需要注意联合索引在创建时的规则(ASC/DESC);
(4)如果不可避免的出现filesort,大数据量排序时,可以适当增大排序缓冲区大小sort_buffer_size(默认256k)。
四、group by优化
4.1、索引初始化(删除除主键索引外的其他索引)
drop index idx_user_pro_age_sta on tb_user;
drop index idx_user_pro on tb_user;
drop index idx_email_5 on tb_user;
drop index idx_user_age_phone on tb_user;
drop index idx_user_age_phone_ad on tb_user;
4.2、测试执行计划
4.2.1、按照profession分组
explain select profession , count(*) from tb_user group by profession ;
4.2.2、创建联合索引后再次执行上述SQL
create index idx_user_pro_age_sta on tb_user(profession , age , status);
4.2.3、依次执行如下SQL
explain select profession , count(*) from tb_user group by profession ;
explain select profession , count(*) from tb_user group by profession,age;
explain select profession , count(*) from tb_user group by profession,age,status;
explain select profession , count(*) from tb_user group by age;
explain select profession , count(*) from tb_user group by status;
结果分析:如果仅仅根据age分组,就会出现 Using temporary ;而如果是根据profession,age两个字段同时分组,则不会出现 Using temporary。原因是因为对于分组操作,在联合索引中,也是符合最左前缀法则的。
4.3、分组优化总结
五、limit优化
5.1、结果分析
通过测试我们会看到,越往后,分页查询效率越低,这就是分页查询的问题所在。 因为当在进行分页查询时,如果执行 limit 2000000,10 ,此时需要MySQL排序前2000010 记录,仅仅返回 2000001 ~ 2000010 的记录,其他记录丢弃,查询排序的代价非常大。
5.2、优化思路
select * from tb_sku t , (select id from tb_sku order by id limit 2000000,10) temp where t.id = temp.id;