精华内容
下载资源
问答
  • COUNT(1) FROM wf_workitem a -- 总数量159521 JOIN wf_activityinst b ON b.id = a.activityinst_id -- 总数量209453 JOIN wf_processinst c ON c.id = b.processinst_id -- 总数量26307 WHERE a.operate_...
  • mysql表数据量超过百万条了,count。。 (15) mysql表数据量超过百万条了,count。。 - MySQL - 乐维UPmysql表数据量超过百万条了,count。。 3 邵琳,一花一世界count一下1800s也不能出结果...

    (15) mysql表数据量超过百万条了,count很慢。。 - MySQL - 乐维UP

     

    3
     
    3dde9d9afdddd5bb34375f3d7cdc3bf6490309

     

    ,一花一世界

    count一下1800s也不能出结果。

    有什么好办法?

    其实我只是想知道具体条数,这个数目在应用中意义不大,

    主要是为了去拿别的小项目时候宣传用。

    其它的操作,插入和查询都挺快了。

     

     

     

    1 条评论

    User_missing_tiny
    别 COUNT 某个 Column 用 COUNT(*) 可能快些。


    2012年05月22日



    ·
    回复

    共 2 个答案

     

    3
     
    56f75da2683faa01d781b1ed1eb7cdf1166156

     

    ,不想做运维的程序员,不是好的架构师

    说两个简单的招

    1) SQL

    你的sql语句怎么写的? 如果是没有任何条件where的 count(*) from table1 , 建议直接使用MyISAM 引擎,因为它自动记录了一个表的总行数,所以这样的查询是几乎不需要读取记录的

    带where的,则必须在where 查询的列加索引(包括group by)

    比如where a=1 and b=2 group by c, 则最好在a,b,c 上建立一个联合索引,至少也要在a上建立一个索引

    2) mysql 调优部分,

    myisam引擎: 增加key_buffer

    innodb: 增加innodb_buffer_pool_size 最重要,其次是 innodb_additional_mem_pool_size

    两者都最好增加query_cache_limit,query_cache_size,read_buffer_size

    posted on 2012-06-25 14:01  lexus 阅读( ...) 评论( ...) 编辑 收藏

    转载于:https://www.cnblogs.com/lexus/archive/2012/06/25/2561160.html

    展开全文
  • Mysqlcount() 问题

    千次阅读 2019-02-21 10:35:18
    不同引擎中,count(*)有不同的实现方式 MyISAM:把一个的总行数存在了磁盘,因此在获取行数时候直接返回,效率高。如果加where条件就不能返回这么快。 InnoDB:需要一行行从引擎里面读出来,累计计数,因为事务的...

    不同引擎中,count(*)有不同的实现方式

    MyISAM:把一个表的总行数存在了磁盘,因此在获取行数时候直接返回,效率高。如果加where条件就不能返回这么快

    InnoDB:需要一行行从引擎里面读出来,累计计数,因为事务的支持所以通过MVCC并发控制,读取行数时候据需要一行行的读出来判断。

    MySQL优化器会找到最小的那棵树来遍历,在保证逻辑正确的前提下,尽量减少扫描的数据量,是数据库系统设计的通用法则之一。

    数据一致性问题目前来说主要分为三类(获取行数)
    1.主从不一致
    解决办法:半同步复制after_commit,after_sync,MGR(after_prepare)。但是都不能完成满足完全实时一致,由于等待的ack点不同,相对来说一致性的强度是递增.
    2.数据库与缓存的不一致
    解决办法:读操作直接读缓存,写操作先更新到数据库,淘汰缓存(程序需要保证两个操作的原子性).由于该key的缓存已经清理掉,那么下次读的时候需要先读数据库,在重建缓存.
    由于redis是单线程,保证了一个操作的原子性.可以通过设置appendfsync always来保证每次操作都把该操作记录并落盘到aof文件里(不过一般redis该值为everysec),毕竟使用redis的目的不是为了保证acid.还是要根据业务来选择;

    把计数放在Redis里面,不能够保证计数和MySQL表里的数据精确一致的原因,是这两个不同的存储构成的系统,不支持分布式事务,无法拿到精确一致的视图。
    3.一个事务跨多个节点或者多种数据库(分库分表和银行转账这种例子)
    InnoDB引擎支持事务,利用好事务的原子性和隔离性,就可以简化在业务开发时的逻辑。

    count(字段值):如果该字段上有null值.每行的行头有一个标记位,标记该行是否为null.所以多了一层判断。相对更耗时


    count(主键id):InnoDB会遍历整张表,把每一行的id值取出来,返回给server层,server层拿到id后,判断是不可能为空的,就按行累加


    count(1):InnoDB遍历整张表,但不去治,server层对返回的每一行,放一个数字1,判断是不可能为空的,按行累加。

    count(*):并不会把全部字段取出来,而是专门做了优化,不取值,*肯定不是null,按行累加。

    count(字段)<count(id)<count(1)≈count(*)

     

     

     

     

    展开全文
  • MySQL45讲】count(*)的问题

    千次阅读 2021-05-20 08:38:20
    但记个总数,每次要查的时候MySQL直接读出来,不就好了么,为什么这么? 接下来聊聊count(*)语句是怎样实现的,以及MySQL为什么会这么实现 接着聊聊应用中有这种频繁变更并需要统计行数的需求,业务设计上可以...

    在开发系统的时候,经常需要计算一个表的行数,比如一个交易系统的所有变更记录总数
    这时候可能会想,一条select count(*) from t语句不就解决了吗?

    但是,发现随着系统中记录数越来越多,这条语句执行得也会越来越慢。但记个总数,每次要查的时候MySQL直接读出来,不就好了么,为什么这么慢?

    接下来聊聊count(*)语句是怎样实现的,以及MySQL为什么会这么实现
    接着聊聊应用中有这种频繁变更并需要统计表行数的需求,业务设计上可以怎么做

    一、count(*)的实现方式

    1.1 不同引擎的实现

    要明确的是,在不同的MySQL引擎中,count(*)有不同的实现方式

    • MyISAM引擎

    把一个表的总行数存在磁盘上,因此执行count(*)的时候会直接返回这个数,效率很高

    • InnoDB引擎

    执行count(*)的时候,需要把数据一行一行地从引擎里面读出来,然后累积计数

    需要注意的是,这个是没有过滤条件的count(*),如果加了where条件,MyISAM表也是不能返回得这么快的

    因为InnoDB不论是在事务支持、并发能力还是在数据安全方面,InnoDB都优于MyISAM,所以大部分都使用了InnoDB引擎,这就是当记录数越来越多的时候,计算一个表的总行数会越来越慢的原因

    1.2 InnoDB实现的背景

    那为什么InnoDB不跟MyISAM一样,也把数字存起来呢?

    这是因为即使是在同一个时刻的多个查询,由于多版本并发控制(MVCC)的原因,InnoDB表应该返回多少行也是不确定的

    用一个count(*)的例子说明一下

    假设表t中现在有10000条记录,设计了三个用户并行的会话:

    1. 会话A先启动事务并查询一次表的总行数
    2. 会话B启动事务,插入一行后记录后,查询表的总行数
    3. 会话C先启动一个单独的语句,插入一行记录后,查询表的总行数

    假设从上到下是按照时间顺序执行的,同一行语句是在同一时刻执行的,会话A、B、C的执行流程:
    在这里插入图片描述
    可以看到,在最后一个时刻,三个会话A、B、C同时查询表t的总行数,但拿到的结果却不同

    这和InnoDB的事务设计有关系,可重复读是它默认的隔离级别,在代码上就是通过多版本并发控制(MVCC)来实现的
    每一行记录都要判断自己是否对这个会话可见,因此对于count(*)请求,InnoDB只好把数据一行一行地读出依次判断,可见的行才能够用于计算基于这个查询的表的总行数

    1.3 InnoDB的优化

    当然,现在这个看上去笨笨的MySQL,在执行count(*)操作的时候还是做了优化的

    • 普通索引树

    InnoDB是索引组织表,主键索引树的叶子节点是数据,而普通索引树的叶子节点是主键值,因此,普通索引树比主键索引树小很多
    对于count(*)这样的操作,遍历哪个索引树得到的结果逻辑上都是一样的,因此,MySQL优化器会找到最小的那棵树来遍历。在保证逻辑正确的前提下,尽量减少扫描的数据量,是数据库系统设计的通用法则之一

    • show table status

    如果使用过show table status命令,就会发现这个命令的输出结果里面也有一个TABLE_ROWS用于显示这个表当前有多少行,这个命令执行很快,那这个TABLE_ROWS 能代替count(*)吗?

    索引统计的值是通过采样来估算的,实际上,TABLE_ROWS就是从这个采样估算得来的,因此也很不准(官方文档说误差可能达到40%到50%)
    所以,show table status命令显示的行数不能直接使用

    到这里小结一下:

    • MyISAM表虽然count(*)很快,但不支持事务
    • show table status命令虽然返回很快,但不准确
    • InnoDB表直接count(*)会遍历全表,虽然结果准确,但会导致性能问题

    回到开始的问题,如果现在有一个页面经常要显示交易系统的操作记录总数,到底应该怎么办呢?
    答案是,只能自己计数

    接下来,讨论一下看看自己计数有哪些方法,以及每种方法的优缺点有哪些
    计数的这些方法的基本思路:需要自己找一个地方,把操作记录表的行数存起来

    二、用缓存系统保存计数

    对于更新很频繁的库来说,可能会第一时间想到,用缓存系统来支持

    2.1 更新机制

    可以用一个Redis服务来保存这个表的总行数
    这个表每被插入一行Redis计数就加1,每被删除一行Redis计数就减1。这种方式下,读和更新操作都很快,但这种方式存在什么问题吗?

    没错,缓存系统可能会丢失更新

    2.2 更新丢失

    • 更新丢失的问题

    Redis的数据不能永久地留在内存里,所以需要找一个地方把这个值定期地持久化存储起来
    但即使这样,仍然可能丢失更新
    试想如果刚刚在数据表中插入了一行,Redis中保存的值也加了1,然后Redis异常重启了,重启后要从存储redis数据的地方把这个值读回来,而刚刚加1的这个计数操作却丢失了

    • 更新丢失的解决

    当然了,这还是有解的
    比如,Redis异常重启以后,到数据库里面单独执行一次count(*)获取真实的行数,再把这个值写回到Redis里就可以了
    异常重启毕竟不是经常出现的情况,这 一次全表扫描的成本,还是可以接受的

    2.3 更新精确度

    实际上,将计数保存在缓存系统中的方式,还不只是丢失更新的问题,即使Redis正常工作,这个值还是逻辑上不精确的

    可以设想一下有这么一个页面,要显示操作记录的总数,同时还要显示最近操作的100条记录
    那么,这个页面的逻辑就需要先到Redis里面取出计数,再到数据表里面取数据记录

    这么定义不精确:

    1. 第一种可能情况,查到的100行结果里面有最新插入记录,而Redis的计数里还没加1
    2. 第二种可能情况,查到的100行结果里没有最新插入的记录,而Redis的计数里已经加了1

    这两种情况,都是逻辑不一致的

    • 先插入数据后更新redis的情况

    看看下面会话A、B执行时序图:

    在这里插入图片描述
    会话A:一个插入交易记录的逻辑,往数据表里插入一行R,然后Redis计数加1
    会话B:查询页面显示时需要的数据

    在这个时序里,在T3时刻会话B来查询的时候,会显示出新插入的R这个记录,但是Redis的计数还没加1,这时候,就会出现我们说的数据不一致

    • 先更新redis后插入数据的情况

    那有可能会说,这是因为执行新增记录逻辑时候,是先写数据表,再改Redis计数。而读的时候是先读Redis,再读数据表,这个顺序是相反的
    那么,如果保持顺序一样的话,是不是就没问题了?现在把会话A的更新顺序换一下,再看看执行结果

    调整顺序后,会话A、B的执行时序图:
    在这里插入图片描述
    这时候反过来了,会话B在T3时刻查询的时候,Redis计数加了1了,但还查不到新插入的R这一行,也是数据不一致的情况

    在并发系统里面,无法精确控制不同线程的执行时刻,因为存在图中的这种操作序列,所以,即使Redis正常工作,这个计数值还是逻辑上不精确的

    三、在数据库保存计数

    根据上面的分析,用缓存系统保存计数有丢失数据和计数不精确的问题
    那么,如果把这个计数直接放到数据库里单独的一张计数表C中,又会怎么样呢?

    首先,这解决了崩溃丢失的问题,InnoDB是支持崩溃恢复不丢数据的

    然后,我们再看看能不能解决计数不精确的问题

    觉得这不一样吗?无非就是把对Redis的操作,改成了对计数表C的操作,只要出现执行序列的情况,这个问题还是无解的吧?

    这个问题还真不是无解的

    要解决的问题都是由于InnoDB要支持事务,从而导致InnoDB表不能把count(*)直接存起来,然后查询的时候直接返回形成的

    所谓以子之矛攻子之盾,现在我们就利用"事务"这个特性,把问题解决掉

    会话A、B的执行时序图如下:
    在这里插入图片描述
    看下现在的执行结果,虽然会话B的读操作仍然是在T3执行的,但是因为这时候更新事务还没有提交,所以计数值加1这个操作对会话B还不可见

    因此,会话B看到的结果里, 查计数值和"最近100条记录"看到的结果,逻辑上就是一致的

    四、不同的count用法

    select count(?) from t这样的查询语句里面, count(*)、count(主键id)、count(字段)和count(1)等不同用法的性能,有哪些差别

    接下来详细说明一下这几种用法的性能差别,需要注意的是,下面的讨论还是基于InnoDB引擎的

    4.1 count()的语义

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

    count(*)、count(主键id)和count(1)都表示返回满足条件的结果集的总行数
    count(字段)则表示返回满足条件的数据行里面,参数"字段"不为NULL的总个数

    4.2 性能分析原则

    分析性能差别的时候,记住这么几个原则:

    1. server层要什么就给什么
    2. InnoDB只给必要的值
    3. 现在的优化器只优化了count(*)的语义为"取行数",其他显而易见的优化并没有做

    4.3 逐个分析

    • count(主键id)

    InnoDB引擎会遍历整张表,把每一行的id值都取出来,返回给server层
    server层拿到id后,判断是不可能为空的,就按行累加

    • count(1)

    InnoDB引擎遍历整张表,但不取值
    server层对于返回的每一行,放一个数字"1"进去,判断是不可能为空的,按行累加

    单看这两个用法的差别的话,能对比出count(1)执行得要比count(主键id)快,因为从引擎返回id会涉及到解析数据行,以及拷贝字段值的操作

    • count(字段)
    1. 如果这个"字段"是定义为not null的话,一行行地从记录里面读出这个字段,判断不能为 null,按行累加
    2. 如果这个"字段"定义允许为null,那么执行的时候,判断到有可能是null,还要把值取出来
      再判断一下,不是null才累加

    符合前面的第一条原则中,server层要什么字段,InnoDB就返回什么字段

    • count(*)

    count()是例外的,并不会把全部字段取出来,而是专门做了优化,不取值
    count(
    )肯定不是null,按行累加

    那优化器不能自己判断一下吗,主键id肯定非空啊,为什么不能按照count(*)来处理,多么简单的优化

    MySQL专门针对这个语句进行优化,也不是不可以,但这种需要专门优化的情况太多了,而且MySQL已经优化过count(*)了,直接使用这种用法就可以

    所以结论是按照效率排序:
    count(字段)<count(主键id)<count(1)count(*)

    因此建议尽量使用count(*)

    展开全文
  • mysql 5.7 innodb 引擎 使用以下几种方法进行统计效率差不多,都不是很高,实际使用中,博客2万条数据就耗时1秒多,效果不堪。在可以为 null 的字段上统计,效率更低。数据如下: select count(*) from blog; ...

    问题描述

    mysql 5.7 innodb 引擎 使用以下几种方法进行统计效率差不多,都不是很高,实际使用中,博客表2万条数据就耗时1秒多,效果不堪。在可以为 null 的字段上统计,效率更低。数据如下:

    select count(*) from blog;
    select count(1) from blog;
    select count(id) from blog;
    (三个差不多,统计25826行,耗时:1.14 sec)
    
    select count(modtime) from blog;
    (modtime可以为null,统计25826行,耗时:1.63 sec)
    

    解决方案:对 id 建立 unique 索引

    ALTER TABLE `blog` 
    ADD UNIQUE INDEX `blog_id`(`id`) USING BTREE;
    

    建立 unique 索引后,再进行统计:

    select count(*) from blog;
    select count(1) from blog;
    select count(id) from blog;
    (三个相同,统计25826行,耗时:0.03 sec)
    
    select count(modtime) from blog;
    (modtime可以为null,统计25826行,耗时:1.51 sec)
    

    原因分析

    • 为什么可以为 null 的字段效率最低:因为每次都要进行判空操作。
    • count(1) count(* ) count(主键)哪个快:实际使用中差不多,本质都是互相调用
    • 为什么主键加 unique 后统计效率会提高几十倍:innodb 引擎统计时大部分情况下统计的是主键,由于主键索引与数据文件存放在一起,所以每次都会扫描数据文件(大量随机io)。加 unique 后,会将主键按规则缓存在内存中,统计时直接统计内存中数据,效率提升几十倍。
    展开全文
  • MySQL 版本:8.0.15 A数据量:2600万+,分区32个,innodb引擎 背景介绍: 由于A是记录数最大的数据,由上线之初的100万数据,迅速增长到500万、1000万,现在数据量在2600万左右。预计未来1年内增长到1亿+。 ...
  • MyISAM引擎把的总行数存在磁盘上,在没有where条件的时候,如果执行count(*),会直接返回这个数。 InnoDB引擎在执行count(*)时,需要把数据一行一行地读出来,累积计数。这是由于InnoDB事务默认的隔离级别是可重复...
  • MySQLcount(1)特别的解决方案.pdf
  • MySQLcount(1)特别的解决方案

    千次阅读 2021-05-01 13:57:37
    mysql里面,统计的行数,大部分情况下,大家都采用select count(1) from table_name where pkid>0 and xxxxx and xxxxxx;这样的方式,去数据库查下返回结果。这种情况下,在小的时候,很快返回,当...
  • MySQL超大如何提高count速度

    千次阅读 2018-07-03 17:01:00
    经常用到count统计记录数,又超级大,这时候sql执行很,就是走索引,也是很的,怎么办呢? 1.这个时候我们就要想为什么这么:根本原因是访问的数据量太大,就算只计算记录数也是很的。 2.如何解决?减少...
  • innodb引擎在统计方面和myisam是不同的,Myisam内置了一个计数器,所以在使用 select count(*) from table 的时候,直接可以从计数器中取出数据。而innodb必须全表扫描一次方能得到总的数量
  • A,B,C数据在200万已经得不行了,少则20多秒,多则数分钟导致超时。 解决方法: 对于count中有join,原因未知,解决方法是加上一项字段较小的且一定会成立的条件 select count(1) from A left join B on A....
  • 发现了mysql innodb count统计特别(无论count(1)还是count(*)),总结一下优化 一般采用二级索引去count: 比如:id 是pk aid是secondary index 采用 select count(*) from table where id &amp;gt;=0; 跟 ...
  • COUNT(*)实现方式 MyISAM引擎把的总行数存在磁盘上; InnoDB引擎从中一行行读出来,然后累计计数; 上述结论基于不加where过滤条件,加了where,MyISAM也没办法返回的那么快; 为什么InnoDB不跟MyISAM一样,也...
  • 博主今天在对一个千万级进行count(*)查询的时候,发现速度有点,达到了9s,这对于程序来说是不可承受的,因此萌生了优化count(*)查询的想法,这里记录一下。 1、网上的主要两种说法 (1)count(*) 函数会选择...
  • 你可能需要给 Primary Key 加上 Uniqle 约束了 ...数据结构: Field Type Null Key Default Extra id int(10) unsigned NO PRI NULL auto_increment mid varchar(50) NO UNI ...
  • Mysql性能优化:为什么count(*)这么

    万次阅读 多人点赞 2020-04-02 22:04:55
    导读在开发中一定会用到统计一张的行数,比如一个交易系统,老板会让你每天生成一个报表,这些统计信息少不了sql中的count函数。但是随着记录越来越多,查询的速度会越来越,为什么会这样...
  • 在不同的MySQL引擎中,count(*)有不同的实现方式。 MyISAM引擎把一个的总行数存在了磁盘上,因此执行count(*)的时候会直接返回这个数,效率很高; InnoDB引擎比较麻烦,执行count(*)的时候,需要把数据一行一行地...
  • 但是发布到线上后,由于阿里云的RDS只支持innodb引擎,因此在执行select count的时候变得特别,基本上要到几十秒,因此各种查找资料,最终得到一个有效的解决办法:使用第二索引来进行查询,如中除了主键ID之外...
  • mysql count 优化问题

    2018-08-24 18:06:10
    使用jdbcTemplate,做统一的分页查询的时候...count(*)在数据量大的时候,总数查询非常, 有什么好的解决方案, count(1)和count(*)就不要说了 也建了适当的索引, 使用结果集的游标直接指向最后能有效果么?
  • mysql innodb count(*)速度且不准确的解决办法innodb引擎在统计方面和myisam是不同的,Myisam内置了一个计数器,所以在使用 select count(*) from table 的时候,直接可以从计数器中取出数据。而innodb必须全表...
  • MySQL count() 函数我们并不陌生,用来统计每张的行数。但如果你的越来越大,且是 InnoDB 引擎的话,会发现计算的速度会越来越。在这篇文章里,会先介绍 count() 实现的原理及原因,然后是 count 不同用法的...
  • mysqlcount(*)的优化,获取千万级数据的总行数

    万次阅读 热门讨论 2018-11-23 17:04:02
    这个问题是今天朋友提出来的,关于查询一个1200w的数据的总行数,用count(*)的速度一直提不上去。找了很多优化方案,最后另辟蹊径,选择了用explain来获取总行数。 二、关于count的优化 &amp;amp;amp;n
  • mysql 全表扫描怎么办

    千次阅读 2018-05-22 20:50:10
    对于like ‘%...%’(全模糊)这样的条件,是无法使用索引的,全表扫描自然效率很低;另外,由于匹配算法的关系,模糊查询的字段长度越大,模糊查询效率越低。解决办法:首先尽量避免模糊查询,如果因为业务需要一定...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 54,699
精华内容 21,879
关键字:

countmysql全表慢

mysql 订阅