面试不是意味着给解决方案，有时候我们也应该质疑问题_MySQL

以下举个数据库相关的面试问题：

CSDN论坛帖子总量的统计，要求实时更新！

MyISAM 存储引擎的情况SELECT COUNT(*)的Query就能解决了！注：MyISAM 存储引擎互联网基本不会选择。

Innodb 存储引擎的情况呢？千万的帖子呢？访问量再大一点呢？

或许有些哥们会想到增加一个统计表，每次有新的帖子产生的时候，都将统计表中统计量这个值增加1，

这个哥们的方法肯定能解决查询的问题不错，但是高峰时期可能每秒就有几十甚至上百个帖子新增操作的时候呢？

又是一场噩梦了，是不是......

其实这种问题我们换个思维，这是一个合理的需求吗？明显需求造成的资源投入产出比相当低。

多少人会关心实时更新的帖子总量统计？有谁会在乎这个数据短时间内的不准确性？

其实去掉实时更新这个问题就很好解决了，创建一张统计表，隔一段时间去统计一次就OK了，不是吗？

这样既可以解决统计值查询的效率问题，又可以保证不影响新发贴的效率，一举两得。

别看这个问题出现的不多，其实实际有很多类似的功能，如：某些表达到一个数量级之后，我们去分页显示他的时候，完全可以

不用准确的显示这个列表总共有多少条信息，总共分了多少页，而只需要一个大概的估计值或者一个时间段之前的统计值就OK了。

这样也可用省去实时大数据的COUNT操作。

总结：从面试题看生产，很多时候我们可用换个角度思考问题，更多的发散思维。

从需求性看实际，并非一味的实时和精准是比较好的，有价值的方案。

从问题出发，我们更需要的是知道问题的本质原因。