这个话题可能看起来很枯燥，但它对mysql的性能优化非常重要。事实上我在MYSQL
咨询工作中无时无刻接不在接触这类问题。
IO工作负载与cpu依赖完全不同，尤其是当你的工作集（通常只有数据库的一小部分）载入内存的时候。当数据在内存中时读取是非常快的，如果不在内存中，则非常缓慢。例如，当你查询分析10000行数据时，如果这10000行全部加载在内存中，则只需要很短时间;但是如果到磁盘上去读的话，我们假设只有10％也就是只需要1000次随机读操作的情况下，这个查询也要花费至少5到10秒，或者在已经超负荷的情况下可能花费更多的时间。
所以在设计应用的时候就应当考虑你的应用属于哪种类型？是否能让应用充分利用CPU或者内存？如果是的话，那么任何种类的困难都不复存在，而且你或许可以采用更容易实现的解决方案。但当你设计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. 更多文章请扫码：
