innodb count(*) 超过 10 亿条记录，怎么破？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

› MySQL 5.5 Community Server

› MySQL 5.6 Community Server

› Percona Configuration Wizard

› XtraBackup 搭建主从复制

Great Sites on MySQL

› Percona

› MySQL Performance Blog

› Severalnines

推荐管理工具

› Sequel Pro

› phpMyAdmin

推荐书目

› MySQL Cookbook

MySQL 相关项目

› MariaDB

› Drizzle

参考文档

› http://mysql-python.sourceforge.net/MySQLdb.html

这是一个创建于 3950 天前的主题，其中的信息可能已经有所发展或是发生改变。

13亿条记录共 53G 数据，属于 log 性质的数据，有事务处理，写入频繁，读虽然不多，但需要可以分页查询。分页就需要 count(*)，众所周知 innodb 的 count() 很慢，怎么办？

换 myisam 就不支持事务了，好纠结

count

亿条

innodb

24 条回复 • 1970-01-01 08:00:00 +08:00

chenlong451

2014-03-04 15:56:15 +08:00

另开一个myisam表，用count字段记录总数，写入的时候更新myisam表。
日志数据没有关联关系，可以用kv数据库，性能问题一下解决。想白天count就白天count，想晚上count就晚上count，再也不会侧漏。

raincious

2014-03-04 16:08:06 +08:00

其实我觉得……弄张表来专门储存统计数据就可以了啊。

比如：
字段：key val
total_topic 10
topic_1_replies 2

这样的，插入/删除数据时更新，事务保证原子性，这样就不用COUNT了。

est

2014-03-04 16:09:08 +08:00

@chenlong451 莫非不是专门开个表记录总数？

shiny

2014-03-04 16:12:26 +08:00

如果条件允许，我喜欢用 redis/memcache 来 incr

whuhacker

2014-03-04 17:38:02 +08:00

@chenlong451 @raincious @est @shiny
不是 count 总数，是带查询条件的 count，所以在另外地方存个总数没啥用

weizhao029

2014-03-04 17:41:58 +08:00

我觉得这种量级的count应该是一个估算数字，不是精确的。所以应该根据实际情况有一个算法出估计的count吧

Ever

2014-03-04 17:48:36 +08:00

@whuhacker 换引擎不用考虑了, myisam快的也仅仅是不带where的count.

gkiwi

2014-03-04 17:48:53 +08:00

此处不清楚你的具体业务，但是你说需要“分页查询”，是否考虑可以只显示前10页的索引！后面用点号省略掉就好。。根据不用不停的向后索引点击再不停的更改查询条件？这样子每次需要做两次查询，一次是取第N页数据，一次是计算这个数量级别上的后面的还剩几页数。

raincious

2014-03-04 18:02:42 +08:00

@whuhacker 嗯……其实我没说总数嗯。

如果数据是常用的，那么最好用专门的统计表来存，插入/删除时变更，用此来替代COUNT。

如果是临时的，比如审计的时候，几个月才用一次的，那么直接COUNT好了，慢点就是等着。

pubby

2014-03-04 21:32:01 +08:00

13亿条，分页毫无意义啊

看看最近1000条么算了

whuhacker

2014-03-04 21:39:26 +08:00

@raincious 数据是用于审计的，客户打电话投诉时我们要拿出 log 的有关证据。慢也不是不能用，只是被同事吐槽很久了……

@pubby 需要进行字段查询的，不只是最近 1000 条那么简单

tokki

2014-03-04 21:42:59 +08:00 via iPhone

@gkiwi 你好

sohoer

2014-03-04 21:58:11 +08:00

单表 10亿。。。

kernel1983

2014-03-04 22:10:52 +08:00

黄金法则, 数据的索引和存储分离

你们一共有多少种查询方式? 归类一下.
存储部分想办法用k/v数据库代替, 另外单独建表索引你要的业务逻辑.

gkiwi

2014-03-04 22:27:06 +08:00

@tokki Hello 魂淡 !

mengzhuo

2014-03-04 23:32:04 +08:00

10亿……莫非是手机短信收费接口记录？

记得当年需求讨论时，某DBA跟我说，直接一个星期换一张表，腰也不酸，腿也不疼了～

yinheli

2014-03-04 23:38:03 +08:00 via iPhone

分表，按时间来，你要查询日志，评估一下日志的时间，一年以前的数据留着实时查询何用？

saharabear

2014-03-04 23:39:43 +08:00

10亿条，不算太大，分几个表就是了。另外，分页也没必要一页一页地分吧？

likuku

2014-03-04 23:48:03 +08:00

非要“即时”扫描整个库...或许只有靠分布式并行查询db了...

jsonline

2014-03-04 23:54:09 +08:00 via Android

分页有实际意义吗？

raincious

2014-03-05 00:07:44 +08:00

@whuhacker 这得看具体情况优化了。

另外分页不一定需要COUNT，可以只给出上一页下一页，用多取一条的方法判断下一页有没有内容就可以了。

下面就是LIMIT慢的问题了，呵呵呵……

nine

2014-03-05 12:06:34 +08:00

先加个二级联合索引试试
把主键和需要order、group的字段加一个联合索引
这样count(*)的时候就走这个索引了

顺便问一句你现在count一次多少时间？

wwek

2014-03-05 20:16:30 +08:00

it系统的基本构架方案里面有一条。
那就是 “拆”。
如果你这个不能拆。那就按照楼上的方法来搞吧。

我还是坚持拆出来。

haython

2014-03-06 12:51:02 +08:00

看看Tokudb这个引擎