MySQL中聚合函数count的使用和性能优化

  COUNT()聚合函数,以及如何优化使用了该函数的查询,极可能是MySQL中最容易被误解的前10个话题之一,在网上随便搜索一下就能看到不少错误的理解,可能比咱们想象的多得多。mysql

在作优化以前,先来看看COUNT()函数的真正做用是什么。sql

COUNT()的做用数据库

COUNT()是一个特殊的函数,有两种很是不一样的做用:它能够统计某个列值的数量也能够统计行数。在统计列值时要求列值非空的(不统计NULL)。若是在COUNT()的括号中指定了列或列的表达式,统计的就是这个表达式有值的结果数。由于不少人对NULL理解有问题,因此这里很容易产生误解。若是想了解更多关于SQL语句中NULL的含义,建议阅读一些关于SQL语句基础的书籍。(关于这个话题,互联网上的一些信息是不够精确的)缓存

COUNT()的另一个做用是统计结果集的行数。当mysql确认括号内的表达式值不可能为空时,实际上就是在统计行数。最简单的就是当咱们使用COUNT(*)的时候,这种状况下通配符*并不会像咱们猜测的那样扩展成全部的列,实际上,它会忽略全部的列而直接统计全部的行数。性能优化

咱们发现一个最多见的错误就是,在括号内指定了一个列却但愿统计结果集的行数。若是但愿知道的是结果集的行数,最好使用COUNT(*),这样写意义清晰,性能也会很好。架构

于MyISAM的神话函数

一个容易产生的误解就是:MyISAM的COUNT()函数老是很是快,不过这是有前提条件的,即只有没有任何where条件的COUNT(*)才很是快,由于此时无需实际地去计算表的行数。MySQL能够利用存储引擎的特性直接得到这个值。若是MySQL知道某列col不可能为NULL值,那么MySQL内部会将COUNT(col)表达式优化为COUNT(*)。性能

当统计带WHERE子句的结果集行数,能够是统计某个列值的数量时,MySQL的COUNT()和其它存储引擎没有任何不一样,就再也不有神话般的速度了。因此在MyISAM引擎表上执行COUNT()有时候比别的引擎快,有时候比别的引擎慢,这受不少因素影响,要视具体状况而定。优化

《高性能MySQL》这本书只介绍了MyISAM存储引擎在count上的误区以及在MyISAM存储引擎上的count优化,而对于经常使用的innodb执行Count没有作过多讲解,下面咱们就聊聊如何在Innodb上进行count优化。.net

 

Innodb存储引擎:

(1)     innodb存储引擎的物理结构包含 表空间、段、区、页、行 五个层级,数据文件按照主键排序存储在页中(页在逻辑上连续),主键的位置即为数据存储位置。

(2)     二级索引存储的数据为指定字段的值与主键值。当咱们经过二级索引统计数据的时候,无需扫描数据文件;而经过主键索引统计数据时,因为主键索引与数据文件存放在一块儿,因此每次都会扫描数据文件,故大多数状况下,经过二级索引统计数据效率 >= 基于主键统计效率。

(3)    因为二级索引存储的数据为指定字段的值与主键值,故在无索引覆盖的状况下,查询二级索引后会根据二级索引获取的主键到主键索引中提取数据,此过程可能形成大量的随机io,致使查询速度较慢。

(4)    因为主键索引与数据存储保持一致,故基于主键的查找数据要比经过二级索引查询数据要快(使用二级索引时,查询到的数据条数>总条数的20%时候mysql就选择全表扫描,但在主键索引上,即便符合条件的达到 90%依然会走索引)。

 

count慢的缘由:

innodb为聚簇索引同时支持事物,其在count指令实现上采用实时统计方式。在无可用的二级索引状况下,执行count会使MySQL扫描全表数据,当数据中存在大字段或字段较多时候,其效率很是低下(每一个页只能包含较少的数据条数,须要访问的物理页较多)。

 

innodb可优化点:

1. 主键须要采用占用空间尽可能小的类型且数据具备连续性(推荐自增整形id),这样有利于减小页分裂、页内数据移动,可加快插入速度同时有利于增长二级索引密度(一个数据页上能够存储更多的数据)。

2.在表包含大字段或字段较多状况下,若存在count统计需求,可建一个较小字段的二级索引(例 char(1) , tinyint )来进行count统计加速。

 

下面作个count优化例子:

1.首先咱们建立一直innodb表,并包含大字段(或包含较多字段):

 

CREATE TABLE `qstardbcontent` (
  `id` BIGINT(20) NOT NULL DEFAULT '0',
  `content` MEDIUMTEXT,
  `length` INT(11)  NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`)
) ENGINE=INNODB DEFAULT CHARSET=utf8

 

2.插入50万条数据,每条数据 5K

 

3.执行select count(*) from qstardbcontent

 

能够看到,近50万条内容较多的数据执行一个count(*) 就须要耗时 13分28秒

下面咱们作个优化,在length字段上加个索引, 执行sql: ALTER TABLE qstardbcontent ADD KEY(LENGTH);

 

索引建完成后,再执行 select count(*) from qstardbcontent;

 

能够看到,整个统计查询很是快,仅用了 354毫秒就完成了查询。

 

加速缘由:

咱们在innodb表上建立了一个二级索引,Innodb在执行count(*)时候由优化器选择执行路径。本例中, 二级索引的存储空间仅包含length字段值、数据主键,假设二级索引辅助结构不占用空间(仅计算数据占用空间),在默认状况下,MySQL的一个数据页大小为16K,一个页可存储的数据条数为 16*1024/(4+8) =1365 ,按照单页存储空间占用为50%(页分裂现象致使页不满)计算,50万条数据的统计仅须要读取约732个物理页,而页在连续的状况下,数据库一次可读取多个连续的页,数据读取总量为 16k*732约 12MB,因mysql空间分配为按区分配,每一个区1M,一次分配1-5个连续区,当数据量较小,一次仅分配一个区,12M数据会分配在12个区中,按照pc硬盘(转速7200转/分) 70m/s 的读取速度,整个过程的io寻址时间(12*8.5ms=102)+读取时间(12m/70m=171ms)=273ms,而数据解析统计约为 30-100ms,故总耗时会在300ms附近(注:count优化功能在5.1版本并不支持)。

1、 基本使用

count的基本做用是有两个:

  • 统计某个列的数据的数量;
  • 统计结果集的行数;

用来获取知足条件的数据的数量。可是其中有一些与使用中印象不一样的状况,好比当count做用一列、多列、以及使用*来表达整行产生的效果是不一样的。

示例表以下:

CREATE TABLE `NewTable` (
`id`  int(11) NULL DEFAULT NULL ,
`name`  varchar(30) NULL DEFAULT NULL ,
`country`  varchar(50) NULL DEFAULT NULL ,
`province`  varchar(30) NULL DEFAULT NULL ,
`city`  varchar(30) NULL DEFAULT NULL 
)ENGINE=InnoDB
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

这里写图片描述

1.1 不计算NULL的值

若是有NULL值,在返回的结果中会被过滤掉

select count(country) from person;
  • 1

返回结果以下:

这里写图片描述

若是知足条件的数据项不存在,则结构返回0,常常经过这种方式判断是否有知足条件的数据存在;返回的数据类型是bigint

1.2 对count(*)的处理

count(*)的处理是有点不一样的,它会返回全部数据的数量,可是不会过滤其中的NULL值,它也并非至关于展开成全部的列,而是直接会忽略全部的列而直接统计全部的行数。语句以下:

select count(*) from person;
  • 1

返回结果以下:

这里写图片描述

当想要返回全部的数据的数量的时候,可是又不想包括所有是NULL的列,使用count(*)是不可能作到的,可是在1.1中说到count做用于列的时候会过滤NULL,那么直接这么写是否是对?

select count(id, `name`, country, province, city) from person;
  • 1

那就错了,count只能做用于单列,不能做用于多列 ,因此上面的写法是错误的。

另外针对count(*)语句,在MyISAM存储引擎中作了优化,每一个表的数据行数都会存储在存储引擎中,能够很快拿到;可是在事务性的存储引擎中,好比InnoDB中,由于会涉及到多个事务;

1.3 对count(distinct …)的处理

count(distinct …)会返回彼此不一样可是非NULL的数据的行数。这一点和只使用distinct是有区别的,由于distinct是不过滤NULL值的,详见MySQL中distinct的使用方法
- 若是没有符合条件的数据则返回0;
- 该语句能够做用于多列,是当各个列之间有一个不一样,就认为整行数据不一样,与distinct做用于多列时效果相同;

select count(DISTINCT country) from person;
  • 1

返回结果以下:

这里写图片描述

可是对于count(*)count(distinct )二者的结合,以下:

select count(DISTINCT *) from person;
  • 1

该语句是错误的,没法执行,所以与select count(DISTINCT *) from person 仍是有区别的。

2、 性能优化

一般状况下,count(*)操做须要大量扫描数据表中的行,若是避免扫描大量的数据就成为优化该语句的关键所在。针对这个问题能够从以下两个角度考虑。

2.1 在数据库的层次上优化

2.1.1 针对count(*)

在MySQL内部已经针对count(*)进行了优化,使用explain查询以下:

EXPLAIN select count(*) from person;
  • 1

这里写图片描述

从中能够看出该查询没有使用全表扫描也没有使用索引,甚至不须要查询数据表,在上面的示例数据库中得知,该库的存储引擎是InnoDB ,并且其中既没有主键也没有索引。

2.2 针对单个列进行count

查询以下:

EXPLAIN select count(country) from person where id > 2;
  • 1

这里写图片描述

发如今没有主键和索引的状况下,对全表进行了扫描。在数据中避免大量扫描数据行,一个最直接的方法使用索引:

  • 当对id设置为通常索引INDEX abc (id) USING BTREE

    执行查询以下:

    EXPLAIN select count(country) from person where id > 2;
    • 1

    结果以下:

    这里写图片描述

    此时发现并无使用索引,仍然进行的是全表扫描,当执行以下时:

    EXPLAIN select count(country) from person where id > 4;
    • 1

    结果以下:

    这里写图片描述

    这是使用了索引进行了范围查询,显然比上面的要好。

    可是问题来了,为何有时候使用索引,有时候不用索引?在上面的第一次查询中已经可以检测出可能的key可是并无使用?若是有知道的大神给解读一下!

  • 对id设置为主键,执行查询以下:

    EXPLAIN select count(country) from person where id > 2;
    • 1

    结果以下:

    这里写图片描述

2.2 在应用的层次上优化

在应用的层次上优化,能够考虑在系统架构中引入缓存子系统,好比在过去中经常使用的Memcached,或者如今很是流行的Redis, 可是这样会增长系统的复杂性。

相关文章
相关标签/搜索