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

[whuhacker]

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

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

[chenlong451]

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

[raincious]

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

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

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

[est]

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

[shiny]

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

[whuhacker]

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

[weizhao029]

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

[Ever]

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

[gkiwi]

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

[raincious]

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

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

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

[pubby]

13亿条，分页毫无意义啊

看看最近1000条么算了

[whuhacker]

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

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

[tokki]

@gkiwi 你好

[sohoer]

单表 10亿 。。。

[kernel1983]

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

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

[gkiwi]

@tokki Hello 魂淡 !

[mengzhuo]

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

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

[yinheli]

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

[saharabear]

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

[likuku]

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

[jsonline]

分页有实际意义吗？