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

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

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

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

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

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

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

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

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

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

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

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

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

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

13亿条，分页毫无意义啊

看看最近1000条么算了

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

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

@gkiwi 你好

单表 10亿 。。。

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

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

@tokki Hello 魂淡 !

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

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

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

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

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

分页有实际意义吗？

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

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

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

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

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

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

我还是坚持拆出来。

看看Tokudb这个引擎