这个话题可能看起来非常枯燥。但它对mysql的性能优化非常重要。其实我在MYSQL咨询工作中无时无刻接不在接触这类问题。
IO工作负载与cpu依赖全然不同。尤其是当你的工作集（通常仅仅有数据库的一小部分）载入内存的时候。
当数据在内存中时读取是很快的，假设不在内存中，则很缓慢。比如，当你查询分析10000行数据时，假设这10000行所有载入在内存中。则仅仅须要很短时间;可是假设到磁盘上去读的话，我们假设仅仅有10％也就是仅仅须要1000次随机读操作的情况下。这个查询也要花费至少5到10秒。或者在已经超负荷的情况下可能花费很多其它的时间。
所以在设计应用的时候就应当考虑你的应用属于哪种类型？能否让应用充分利用CPU或者内存？假设是的话。那么不论什么种类的困难都不复存在，并且你也许能够採用更easy实现的解决方式。但当你设计CPU依赖型应用的时候要注意，当它规模过大时你可能负担不起更大的内存需求，同一时候性能还会急剧下降。并且随着复杂变化的发生你的应用訪问速度可能变得糟糕。
CPU依赖在处理大量数据时比IO依赖更有优势：Count查询。分组查询，无索引排序。搜索查询等。基本上查询分析超过100行数据并且是“随机訪问”大数据量的表（这种情况下。须要频繁的物理IO操作）我想强调的是。这种查询可能会遇到性能问题。
同一时候。也不要仅仅看“典型”案例。在非常多情况下性能方面的问题可能就是这最糟糕的5%导致的。
让我来举个简单的样例来说明一下，假设你的应用中用户之间有某种格式的通信。
您可能希望显示用户未读消息数以及邮箱中的邮件总数来至少“画出页面”。简单的解决方式是运行select count(*) from messages where user_id=134 语句或者在祝查询中使用SQL_CALC_FOUND_ROWS标记来查询相关数据。
假设你的应用是CPU依赖型，那么你可能须要做的就是在数据库之上做一次缓存；假设你的应用为IO依赖型，那么你可能会有麻烦，即使邮箱中仅仅有1000条信息也会使速度变慢。
如果如今你有一部分很活跃的用户。他们的邮箱中邮件数可能许多，达到一个极端。那么载入这些信息将花费很长时间--产生的负载也比普通用户多，并且由于他们对整个应用的贡献很大所以你不想由于页面载入慢而激怒这部分用户。
所以，对于IO依赖型应用，你须要创建字段来记录信息总数、已读信息数等；须要确保同步更新这新字段（如使用触发器）；确保全部查询使用order by ... limit语句索引。
对于IO依赖型应用来说，聚集索引（数据本地化）也是非常重要的--假设使用的是Innodb引擎的表，使用被auto_increment标记的自增列作索引非常可能比使用如(user_id,sub_id)这样的符合主键要慢，这是由于这样的索引能够将user_id同样的信息聚集起来并且通常同意通过非常少物理IO来查询这些数据。
你可能会觉得你在CPU依赖型设计场景中也会碰到这类问题--是的，可是你可能是在100,000条信息的时候遇到性能问题而不是像IO依赖型应用中在100条信息的时候就会碰到这个问题。而这100,000条对大多数应用来说已经够用了，不用去过多考虑这个问题。
1. 本文由程序猿学架构翻译
2. 本文译自Are you designing IO bound or CPU bound application ? | MySQL Performance Blog
3. 转载请务必注明本文出自：程序猿学架构(微信号：archleaner )
4. 很多其它文章请扫码：