MySQL 大表的count()优化实现

以下是基于我结合B+树的数据结构和对实验结果的推测作出的判断,如有错误,恳请指正!

今天实验了一下MySQL的count()操作优化, 以下讨论基于mysql5.7 InnoDB存储引擎. x86 windows操作系统。

创建的表的结构如下(数据量为100万):

首先是关于mysql的count(*),count(PK), count(1)哪个快的问题。
实现结果如下:

并没有什么区别!加上了WHERE子句之后3个查询的时间也是相同的,我就不贴图片了。

之前在公司的时候就写过一个select count(*) from table的SQL语句,在数据多的时候非常慢。所以要怎么优化呢?

这要从InnoDB的索引说起, InnoDB的索引是B+Tree。

对主键索引来说:它只有在叶子节点上存储数据,它的key是主键,并且value为整条数据
对辅助索引来说:key为建索引的列,value为主键。

这给我们两个信息:
1. 根据主键会查到整条数据
2. 根据辅助索引只能查到主键,然后必须通过主键再查到剩余信息。

所以如果要优化count(*)操作的话,我们需要找一个短小的列,为它建立辅助索引。
在我的例子中就是status,虽然它的”severelity”几乎为0.

先建立索引:ALTER TABLE test1 ADD INDEX (status);
然后查询,如下图:

可以看到,查询时间从3.35s下降到了0.26s,查询速度提升近13倍

如果索引是str这一列,结果又会是怎么样呢?
先建立索引: alter table test1 add index (str)
结果如下:

可以看到,时间为0.422s,也很快,但是比起status这列还是有着1.5倍左右的差距。

再大胆一点做个实验,我把status这列的索引删掉,建立一个statusleft(omdb,200)(这一列平均1000个字符)的联合索引,然后看查询时间。
建立索引: alter table test1 add index (status,omdb(200))
结果如下:

时间为1.172s

alter table test1 add index (status,imdbid);

补充!!
要注意索引失效的情况!
建立了索引后正常的的样子:

可以看到key_len为6, Extra的说明是using index.

而如果索引失效的话:

索引失效有很多种情况,比如使用函数,!=操作等,具体请参考官方文档。

对MySQL没有很深的研究,以上是基于我结合B+树的数据结构和对实验结果的推测作出的判断,如有错误,恳请指正!

到此这篇关于MySQL 大表的count()优化实现的文章就介绍到这了,更多相关MySQL 大表count()优化内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

时间: 2021-03-29

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

本文的环境是Windows 10,MySQL版本是5.7.12-log 一. 基本使用 count的基本作用是有两个: 统计某个列的数据的数量: 统计结果集的行数: 用来获取满足条件的数据的数量.但是其中有一些与使用中印象不同的情况,比如当count作用一列.多列.以及使用*来表达整行产生的效果是不同的. 示例表如下: CREATE TABLE `NewTable` ( `id` int(11) NULL DEFAULT NULL , `name` varchar(30) NULL DEFAUL

关于mysql中innodb的count优化问题分享

一般采用二级索引去count:比如:id 是pk aid是secondary index 采用 复制代码 代码如下: select count(*) from table where id >=0;或select count(*) from table; 效果是一样的,都是默认使用pk索引,且都要全表扫描,虽然第一种性能可能高一些,但是没有明显区别. 但是如果用secondary index 复制代码 代码如下: select count(*) from table where aid>=0;

MySQL中Innodb的事务隔离级别和锁的关系的讲解教程

前言: 我们都知道事务的几种性质,数据库为了维护这些性质,尤其是一致性和隔离性,一般使用加锁这种方式.同时数据库又是个高并发的应用,同一时间会有大量的并发访问,如果加锁过度,会极大的降低并发处理能力.所以对于加锁的处理,可以说就是数据库对于事务处理的精髓所在.这里通过分析MySQL中InnoDB引擎的加锁机制,来抛砖引玉,让读者更好的理解,在事务处理中数据库到底做了什么. 一次封锁or两段锁? 因为有大量的并发访问,为了预防死锁,一般应用中推荐使用一次封锁法,就是在方法的开始阶段,已经预先知道会

设置MySQL中的数据类型来优化运行速度的实例

今天看了一个优化案例觉的挺有代表性,这里记录下来做一个标记,来纪念一下随便的字段定义的问题. 回忆一下,在表的设计中很多人习惯的把表的结构设计成Varchar(64),Varchar(255)之类的,虽然大多数情况只存了5-15个字节.那么我看一下下面这个案例. 查询语句: SELECT SQL_NO_CACHE channel, COUNT(channel) AS visitors FROM xxx_sources WHERE client_id = 1301 GROUP BY client_

MySQL中InnoDB存储引擎的锁的基本使用教程

MyISAM和MEMORY采用表级锁(table-level locking) BDB采用页面锁(page-leve locking)或表级锁,默认为页面锁 InnoDB支持行级锁(row-level locking)和表级锁,默认为行级锁 各种锁特点 表级锁:开销小,加锁快:不会出现死锁:锁定粒度大,发生冲突的概率最高,并发度最低 行级锁:开销大,加锁慢:会出现死锁:锁定粒度最小,发生锁冲突的概率最低,并发度也最高 页面锁:开销和加锁时间介于表锁和行锁之间:会出现死锁:锁定粒度介于表锁和行锁之

大幅提升MySQL中InnoDB的全表扫描速度的方法

 在 InnoDB中更加快速的全表扫描  一般来讲,大多数应用查询的时候都会用索引,查找很少的几行数据(主键查找或百行内的查询),但有时候我们需要全表查询.典型的全表扫描就是逻辑备份  (mysqldump) 和 online schema changes( 注:在线上对大表 schema 的操作,也是 facebook 的一个开源项目) (SELECT ... INTO OUTFILE). 在 Facebook我们用 mysqldump 来备份数据库. 正如你所知MySql提供两种备份方式,提

MySQL中distinct和count(*)的使用方法比较

首先对于MySQL的DISTINCT的关键字的一些用法: 1.在count 不重复的记录的时候能用到,比如SELECT COUNT( DISTINCT id ) FROM tablename:就是计算talbebname表中id不同的记录有多少条. 2,在需要返回记录不同的id的具体值的时候可以用,比如SELECT DISTINCT id FROM tablename:返回talbebname表中不同的id的具体的值. 3.上面的情况2对于需要返回mysql表中2列以上的结果时会有歧义,比如SE

详解MySQL中InnoDB的存储文件

从物理意义上来讲,InnoDB表由共享表空间文件(ibdata1).独占表空间文件(ibd).表结构文件(.frm).以及日志文件(redo文件等)组成. 1.表结构文件 在MYSQL中建立任何一张数据表,在其数据目录对应的数据库目录下都有对应表的.frm文件,.frm文件是用来保存每个数据表的元数据(meta)信息,包括表结构的定义等,.frm文件跟数据库存储引擎无关,也就是任何存储引擎的数据表都必须有.frm文件,命名方式为数据表名.frm,如user.frm. .frm文件可以用来在数据库

mysql中is null语句的用法分享

mysql数据库中is null语句的用法 注意在mysql中,0或 null意味着假而其它值意味着真.布尔运算的默认真值是1. 对null的特殊处理即是在前面的章节中,为了决定哪个动物不再是活着的,使用death is not null而不使用death != null的原因. 在group by中,两个null值视为相同. 执行order by时,如果运行 order by ... asc,则null值出现在最前面,若运行order by ... desc,则null值出现在最后面. nul

mysql 中InnoDB和MyISAM的区别分析小结

MyIASM是IASM表的新版本,有如下扩展: 二进制层次的可移植性. NULL列索引. 对变长行比ISAM表有更少的碎片. 支持大文件. 更好的索引压缩. 更好的键吗统计分布. 更好和更快的auto_increment处理. 以下是一些细节和具体实现的差别: 1.InnoDB不支持FULLTEXT类型的索引. 2.InnoDB 中不保存表的具体行数,也就是说,执行select count(*) from table时,InnoDB要扫描一遍整个表来计算有多少行,但是MyISAM只要简单的读出保