在面试的时候你会被问到各种各样的怪问题，在绞尽脑汁想着解决方案的时候你或许可以从实际的角度给出最完美的方案。 以下举个数据库相关的面试问题： CSDN论坛帖子总量的统计，要求实时更新！ MyISAM 存储引擎的情况SELECT COUNT(*)的Query就能解决了！注：M
在面试的时候你会被问到各种各样的怪问题，在绞尽脑汁想着解决方案的时候你或许可以从实际的角度给出最完美的方案。
以下举个数据库相关的面试问题：
CSDN论坛帖子总量的统计，要求实时更新！
MyISAM 存储引擎的情况SELECT COUNT(*)的Query就能解决了！注：MyISAM 存储引擎互联网基本不会选择。
Innodb 存储引擎的情况呢？千万的帖子呢？访问量再大一点呢？
或许有些哥们会想到增加一个统计表，每次有新的帖子产生的时候，都将统计表中统计量这个值增加1，
这个哥们的方法肯定能解决查询的问题不错，但是高峰时期可能每秒就有几十甚至上百个帖子新增操作的时候呢？
又是一场噩梦了，是不是......
其实这种问题我们换个思维，这是一个合理的需求吗？明显需求造成的资源投入产出比相当低。
多少人会关心实时更新的帖子总量统计？有谁会在乎这个数据短时间内的不准确性？
其实去掉实时更新这个问题就很好解决了，创建一张统计表，隔一段时间去统计一次就OK了，不是吗？
这样既可以解决统计值查询的效率问题，又可以保证不影响新发贴的效率，一举两得。
别看这个问题出现的不多，其实实际有很多类似的功能，如：某些表达到一个数量级之后，我们去分页显示他的时候，完全可以
不用准确的显示这个列表总共有多少条信息，总共分了多少页，而只需要一个大概的估计值或者一个时间段之前的统计值就OK了。
这样也可用省去实时大数据的COUNT操作。
总结：从面试题看生产，很多时候我们可用换个角度思考问题，更多的发散思维。
从需求性看实际，并非一味的实时和精准是比较好的，有价值的方案。
从问题出发，我们更需要的是知道问题的本质原因。
