【SQL优化】

学习的小韩

已于 2023-04-25 22:51:26 修改

阅读量134

点赞数

分类专栏： mysql 文章标签： sql 数据库 mysql

于 2023-04-24 18:40:43 首次发布

本文链接：https://blog.csdn.net/m0_45263525/article/details/130349259

版权

mysql 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

sql优化

1.insert优化

假如我们需要一次性插入多条数据，每条insert语句都要与MySQL建立连接进行网络传输。

insert into tb_test values(1,'tom');
insert into tb_test values(2,'cat');
insert into tb_test values(3,'jerry');

优化方案：

①批量插入

一次性插入不超过1000条，超过了分割成多条insert语句进行插入

Insert into tb_test values(1,'Tom'),(2,'Cat'),(3,'Jerry');

②手动控制事务

多条insert语句统一提交

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;

③主键顺序插入

大批量插入数据，假如插入100万条数据，使用insert语句插入性能较低，这时可以使用MySQL为我们提供的load指令，直接加载文件中的数据，文件每个字段按逗号分割。

-- 客户端连接服务端时，加上参数 -–local-infile
mysql –-local-infile -u root -p

-- 设置全局参数local_infile为1，开启从本地加载文件导入数据的开关
set global local_infile = 1;

-- 执行load指令将准备好的数据，加载到表结构中
load data local infile '/root/sql1.log' into table tb_user fields terminated by ',' lines terminated by '\n' ;

2.主键优化

1）数据组织形式

在InnoDB存储引擎中，表数据都是根据主键顺序组织存放的，这种存储方式的表称为索引组织表

行数据，都是存储在聚集索引的叶子节点上的。而我们之前也讲解过InnoDB的逻辑结构图：

在InnoDB引擎中，数据行是记录在逻辑结构 page 页中的，而每一个页的大小是固定的，默认16K。

那也就意味着，一个页中所存储的行也是有限的，如果插入的数据行row在该页存储不小，将会存储到下一个页中，页与页之间会通过指针连接。

2）页分裂

页可以为空，也可以填充一半，也可以填充100%。每个页包含了2-N行数据(如果一行数据过大，会行溢出)，根据主键排列。

①按主键顺序插入

该页写满后写下一个页，页与页之间使用指针相连。不会出现什么性能损耗问题

②按主键乱序插入

假如1，2页都写满了，如图

此时再插入id为50的记录，我们来看看会发生什么现象

因为索引结构的叶子节点是有顺序的。按照顺序，应该存储在47之后。但是47所在的1#页，已经写满了，存储不了50对应的数据了。那么此时会开辟一个新的页 3#。

但是并不会直接将50存入3#页，而是会将1#页后一半的数据，移动到3#页，然后在3#页，插入50。

移动数据，并插入id为50的数据之后，那么此时，这三个页之间的数据顺序是有问题的。 1#的下一个页，应该是3#， 3#的下一个页是2#。所以，此时，需要重新设置链表指针。

上述的这种现象，称之为 “页分裂”，是比较耗费性能的操作。

3）页合并

目前表中已有数据的索引结构(叶子节点)如下：

当我们对已有数据进行删除时，具体的效果如下:

当删除一行记录时，实际上记录并没有被物理删除，只是记录被标记（flaged）为删除并且它的空间变得允许被其他记录声明使用。插入数据直接进行覆盖。

当我们删除的记录达到MERGE_THRESHOLD（默认为页的50%），InnoDB会开始寻找最靠近的页（前或后）看看是否可以将两个页合并以优化空间使用。

这个里面所发生的合并页的这个现象，就称之为 “页合并”。

注意：

MERGE_THRESHOLD：合并页的阈值，可以自己设置，在创建表或者创建索引时指定。

4）索引设计原则

满足业务需求的情况下，尽量降低主键的长度。
插入数据时，尽量选择顺序插入，选择使用AUTO_INCREMENT自增主键。
尽量不要使用UUID做主键或者是其他自然主键，如身份证号。
业务操作时，避免对主键的修改。

3.order by优化

MySQL的排序，有两种方式：

① Using filesort : 通过表的索引或全表扫描，读取满足条件的数据行，然后在排序缓冲区sort buffer中完成排序操作，所有不是通过索引直接返回排序结果的排序都叫 FileSort 排序。

② Using index : 通过有序索引顺序扫描直接返回有序数据，这种情况即为 using index，不需要额外排序，操作效率高。

对于以上的两种排序方式，Using index的性能高，而Using filesort的性能低，我们在优化排序操作时，尽量要优化为 Using index。

优化原则：

A. 根据排序字段建立合适的索引，多字段排序时，也遵循最左前缀法则。

B. 尽量使用覆盖索引。

C. 多字段排序, 一个升序一个降序，此时需要注意联合索引在创建时的规则（ASC/DESC）。

D. 如果不可避免的出现filesort，大数据量排序时，可以适当增大排序缓冲区大小 sort_buffer_size(默认256k)。

4.group by优化

对普通字段class_id进行分组，执行explain发现Extra字段中有Using temporary
explain select class_id ,count(*) as num from student group by class_id;
Extra 这个字段的Using temporary表示在执行分组的时候使用了临时表

为什么会用到临时表？

执行上述sql语句的流程：

创建内存临时表，表里有两个字段class_id和num；

全表扫描student的记录，依次取出class_id = 'X’的记录。

判断临时表中是否有为 class_id='X’的行，没有就插入一个记录 (X,1);
如果临时表中有class_id='X’的行的行，就将x 这一行的num值加 1；

我们可以对class_id加索引，我们知道索引会自动排序，也就会相同字段在连续位置。

然后再执行执行计划查看Extra字段

总结：

如果我们使用多个字段分组，我们也可以对多个字段建立索引，但要满足最左前缀法则。

A. 在分组操作时，可以通过索引来提高效率。

B. 分组操作时，索引的使用也是满足最左前缀法则的。

5.limit优化

①深分页问题：

问题分析：假设我们用户表有1000万数据，当我们执行下列语句，发现速度很快
select * from user 
where create_time>'2023-04-03' 
limit 0,10;
但是当我们执行下列语句时，会发现速度急剧下降。
select * from user 
where create_time>'2022-07-03' 
limit 1000000,10;
为什么？

通过查阅发现，我们查询从100万行开始的后10行数据时，我们要从第一个开始查询，查到1000010数据，再把前100万条数据舍弃，这样我们就做了100万次无效查询，而且我们是通过二级索引进行的查询，还要回表100万条数据，所以速度急剧下降。

②优化1：使用子查询

先用子查询查出符合条件的主键，再用主键ID做条件查出所有字段。避免回表的时间损耗。

select * from user 
where id in (
  select id from user 
  where create_time>'2022-07-03' 
  limit 100000,10
);

发现报错不支持子查询中含有limit。

于是我们嵌套一层子查询

select * from user 
where id in (
 select id from (
    select id from user 
    where create_time>'2022-07-03' 
    limit 100000,10
 ) as t
);

发现时间有所提升，这里的提升主要是对之前回表时间的节省，之前需要先查询出1000010条id，去回表这么多条数据，再丢弃前100万条数据得到这10条数据，现在直接拿出1000010条id，舍弃前100万条id，通过完成查询直接拿到这10条数据。

③优化2：使用分页游标

把前一页的查询结果放到下一页的查询条件中

如下：假设前一页查询结果最大为id=10000，下一页直接从10000开始查。

仅适合一页一页向后走的场景，当我们直接指定某页查询是不行的。

select * from user 
where create_time>'2022-07-03' and id>10000 
limit 10;

6.count优化

数据量很大时，我们发现count(*)是非常耗时的。

MyISAM 引擎把一个表的总行数存在了磁盘上，因此执行 count(*) 的时候会直接返回这个数，效率很高；但是如果是带条件的count，MyISAM也慢。
InnoDB 引擎就麻烦了，它执行 count(*) 的时候，需要把数据一行一行地从引擎里面读出来，然后累积计数。

count(主键): InnoDB 引擎会遍历整张表，把每一行的主键id 值都取出来，返回给服务层。服务层拿到主键后，直接按行进行累加(主键不可能为null)
count(字段):
- 没有not null 约束 : InnoDB 引擎会遍历整张表把每一行的字段值都取出来，返回给服务层，服务层判断是否为null，不为null，计数累加。
- 有not null 约束：InnoDB 引擎会遍历整张表把每一行的字段值都取出来，返回给服务层，直接按行进行累加。
count(数字):InnoDB 引擎遍历整张表，但不取值。服务层对于返回的每一行，放一个数字“1”进去，直接按行进行累加。
count(*):InnoDB引擎并不会把全部字段取出来，而是专门做了优化，不取值，服务层直接按行进行累加。

按照效率排序的话，count(字段) < count(主键 id) < count(1) ≈ count()，所以尽量使用 count()。

7.update优化

InnoDB的行锁是针对索引加的锁，不是针对记录加的锁 ,并且该索引不能失效，否则会从行锁升级为表锁。

例：假如id为主键，当我们在执行更新的SQL语句时，会锁定id为1这一行的数据，然后事务提交之后，行锁释放。

update course set name = 'hjh' where id = 1 ;

假设name为普通字段，当我们开启多个事务，在执行下列的SQL时，我们发现行锁升级为了表锁。其他事务对该表进行操作时会阻塞。导致该update语句的性能大大降低。

update course set name = 'Wang' where name = 'Li' ;

所以我们可以对name字段创建索引，避免表锁的损耗。