Innodb引擎中Count(*)

select count(*)是MySQL中用于统计记录行数最常用的方法,count方法可以返回表内精确的行数。

在某些索引下是好事,但是如果表中有主键,count(*)的速度就会很慢,特别在千万记录以上的大表。

所以、如果是用Innodb引擎的时候,使用select count(*)语句时,建议采用二级索引速度会比用主键索引更快。

在InnoDB引擎中,当我们通过二级索引统计数据的时候,无需扫描数据文件(二级索引存储指定字段的索引,实际的指向位置是主键索引。);而通过主键索引统计数据时,由于主键索引与数据文件存放在一起,所以每次都会扫描数据文件,所以主键索引统计没有二级索引效率高。

而myisam是不同的,Myisam内置了一个计数器,所以在使用 select count(*) from table 的时候,直接可以从计数器中取出数据。

所以,在myisam引擎执行count(*)速度非常快,而且执行速度与记录条数无关,而innodb却不是这样。

原文地址:https://www.cnblogs.com/yswyzh/p/9697330.html

时间: 2024-10-11 23:28:49

Innodb引擎中Count(*)的相关文章

为啥select count(_) from t,在InnoDB引擎中比MyISAM 慢

感谢参考原文-http://bjbsair.com/2020-04-01/tech-info/18472.html 统计一张表的总数量,是我们开发中常有的业务需求,通常情况下,我们都是使用 select count(*) from t SQL 语句来完成.随着业务数据的增加,你会发现这条语句执行的速度越来越慢,为什么它会变慢呢? 为什么会变慢?想要得到答案就需要知道 MySQL 是如何统计总数量的,先说一个前提吧,count() 的具体实现是由存储引擎实现的,也就是说不同的存储引擎实现的方式不一

MySQL下InnoDB引擎中的Memcached插件

安装 为了让文章更具完整性,我们选择从源代码安装MySQL,需要注意的是早期的版本有内存泄漏,所以推荐安装最新的稳定版,截至本文发稿时为止,最新的稳定版是5.6.13,我们就以此为例来说明,过程很简单,只要激活了WITH_INNODB_MEMCACHED即可: ?123456789101112131415 shell> groupadd mysql shell> useradd -r -g mysql mysql shell> tar zxvf mysql-5.6.13.tar.gz s

谈谈 InnoDB引擎中的一些索引策略

如果我们在工作能够更好的利用好索引,那将会极大的提升数据库的性能. 覆盖索引 覆盖索引是指在普通索引树中可以得到查询的结果,不需要在回到主键索引树中再次搜索 建立如下这张表来演示覆盖索引: create table T ( id int primary key, age int NOT NULL DEFAULT 0, name varchar(16) NOT NULL DEFAULT '', index age(age)) engine=InnoDB; 我们执行select * from T w

MySQL5使用Innodb引擎时如何设置数据文件按表存储

在Innodb引擎中,数据库的表可以共享存储空间也可以按表单独存储,共享存储空间虽然看起来简洁干净,但是从管理和运维的角度的看这种方式不可取.首先在同一个MySQL服务器下得不通数据库的表都会被存放于一个文件中,这个文件不会以为数据库某个表或者某些数据的删除二进行收缩,当数据库很多并且插入操作频繁的情况下,共享存储文件会增长的很快很大.如果数据库要做迁移,架构比较简单,但是存储于共享空间的中的数据就不太容易分离出来. 如果使用按表单独存储则可以很好的解决上述问题,遗憾的是MySQL5中使用Inn

ThinkPHP5查询当前表引擎,以及InnoDB表引擎下count(*)查询效率低的问题

今天新开发的功能上线之后出现了查询效率极其低下的问题,查询日志后发现问题出在代码内的大量的count()查询上,最严重时一条简单的count()查询执行时间长达120多秒! 针对这个问题请教前辈后被告知原因:InnoDB引擎下的count()语句会在实时查询表中的所有数据后返回总数所以效率较低,而MyISAM引擎则是直接返回表内存储的行记录信息所以效率较高.因为我本地的数据库引擎为MyISAM而线上的阿里云数据库服务器引擎为InnoDB所以出现了这种本地环境与线上环境查询效率差距极大的问题. 并

MySQL中innodb引擎分析(初始化)

MySQL的存储引擎是以插件形式工作的,这应该是MySQL的一大特色了吧! 依据<深入理解MySQL>的内容,5.1版本号时存储引擎的插件化都还不是彻底,确切的说是刚加入的特性.为MySQL加入一个存储引擎时,须要更改一些上层代码,零散的更改本来就有点麻烦,同一时候project也要又一次编译一次.我听别人说,已经能够不改C/C++代码就直接加入引擎了.这种话,折腾存储引擎的话就更方便了! 这段代码来自ha_innodb.cc,这是MySQL中申明存储引擎插件的标准过程.这段代码利用了宏.在p

MySQL 温故而知新--Innodb存储引擎中的锁

近期碰到非常多锁问题.所以攻克了后,细致再去阅读了关于锁的书籍,整理例如以下:1,锁的种类 Innodb存储引擎实现了例如以下2种标准的行级锁: ? 共享锁(S lock),同意事务读取一行数据. ?  排它锁(X lock).同意事务删除或者更新一行数据. 当一个事务获取了行r的共享锁.那么另外一个事务也能够马上获取行r的共享锁,由于读取并未改变行r的数据.这样的情况就是锁兼容. 可是假设有事务想获得行r的排它锁,则它必须等待事务释放行r上的共享锁-这样的情况就是锁不兼容.二者兼容性例如以下表

MySQL5.5索引数在InnoDB引擎内与索引数在mysql中定义的数量是不一致问题

在查看MySQL错误日志的时候发现这样的错误,如下: 160322 21:42:59 [ERROR] Table baby/baby_order contains 12 indexes inside InnoDB, which is different from the number of indexes 11 defined in the My SQL 大概意思是说表baby_order的索引数在InnoDB引擎内与索引数在mysql中定义的数量是不一致的 为什么会出现这样的错误呢? 参考了这

MYSQL 5.6中禁用INNODB引擎

并不是所有人都需要INNODB引擎,虽然它弥补了MYSQL缺乏事务支持的毛病,但是它的磁盘性能一直是让人比较担忧的.另外比较老的PHP系统,大多是采用MYISAM引擎在MYSQL建表,似乎INNODB根本用不上场,这时候可以考虑将INNODB禁掉.在MYSQL 5.6中,直接skip-innodb前面的注释后,在my.ini中要设置一下:default-storage-engine=MYISAMdefault-tmp-storage-engine=MYISAM上面橙色字是必须要加的一行,否则MY