23.MySql group by优化、limit优化、 count优化、update优化

group by优化

分组操作,我们主要来看看索引对于分组操作的影响。

首先我们先将 tb_user 表的索引全部删除掉。

接下来,在没有索引的情况下,执行如下SQL,查询执行计划:

csharp 复制代码
explain select profession, COUNT(*) from tb_user group by profession;

Using temporary 用到临时表效率低

然后,我们在针对于profession, age, status 创建一个联合索引。

csharp 复制代码
create index idx_user_pro_age_sta on tb_user(profession,age,status);

show index from tb_user;

紧接着,再执行前面相同的SQL查看执行计划。

csharp 复制代码
explain select profession, COUNT(*) from tb_user group by profession;
csharp 复制代码
explain select age, COUNT(*) from tb_user group by age;

我们发现,如果仅仅根据age分组,就会出现Using temporary;而如果是根据 profession,age两个字段同时分组,则不会出现Using temporary。原因是因为对于分组操作,在联合索引中,也是符合最左前缀法则的。

所以,在分组操作中,我们需要通过以下两点进行优化,以提升性能:

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

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

limit优化

在数据量比较大时,如果进行limit分页查询,在查询时,越往后,分页查询效率越低。

优化思路: 一般分页查询时,通过创建覆盖索引能够比较好地提高性能,可以通过覆盖索引加子查询形式进行优化。

vbnet 复制代码
explain select * from tb_sku t , (select id from tb_sku order by id limit 2000000,10) a where t.id = a.id;

count优化

如果数据量很大,在执行count操作时,是非常耗时的。

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

如果说要大幅度提升InnoDB表的count效率,主要的优化思路:自己计数(可以借助于redis这样的数据库进行,但是如果是带条件的count又比较麻烦了)。

count用法

count() 是一个聚合函数,对于返回的结果集,一行行地判断,如果 count 函数的参数不是 NULL,累计值就加 1,否则不加,最后返回累计值。

用法:count(*)、count(主键)、count(字段)、count(数字)

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(*)。

update优化 我们主要需要注意一下update语句执行时的注意事项。

bash 复制代码
update course set name = 'javaEE' where id = 1 ;

当我们在执行删除的SQL语句时,会锁定id为1这一行的数据,然后事务提交之后,行锁释放。 但是当我们在执行如下SQL时。

ini 复制代码
update course set name = 'SpringBoot' where name = 'PHP' ;

当我们开启多个事务,在执行上述的SQL时,我们发现行锁升级为了表锁。 导致该update语句的性能大大降低。

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

相关推荐
唐青枫3 天前
MySQL JSON 实战详解:从存储、查询、更新到 JSON_TABLE 与索引
sql·mysql
小满8783 天前
5.Mysql事务隔离级别与锁机制
mysql
元Y亨H3 天前
技术笔记:MySQL 字符集排序规则与大小写敏感性问题解决方案
mysql
这个DBA有点耶4 天前
GROUP BY优化全解:如何写出既不丢数据又飞快的分组查询
数据库·mysql·架构
掉头发的王富贵4 天前
【StarRocks】极限十分钟入门StarRocks
数据库·sql·mysql
SamDeepThinking5 天前
一条UPDATE语句在MySQL 8.0中到底加了几把锁?
后端·mysql·程序员
李白客6 天前
KES新版MySQL兼容能力再升级意味着什么?
mysql·国产数据库
Jim6008 天前
【吃透 MySQL InnoDB连载】第 1 章・解密线上数据库高频故障
mysql
GreatSQL9 天前
gt-checksum v4.0.0 新功能解读系列文章(4):SSL 加密连接——数据校验传输安全再升级
mysql