多数Web数据库都有人们称之为“高度事务型”的工作负荷，你也可能听说过这称为OLTP(在线事务处理)。这名字有点误导，因为这通常并不意味着正在运行金融事务，在SOL意义上甚至也不意味着是数据库事务。通常只是意味着应用程序做一些混合着读写一些行或一些行集的工作而已。很多互联网应用都匹配下面的模式。

● 应用程序读得多，读对写的比率范围从读五次写一次到读十次写一次不等，甚至一路飙升到读几百次オ写一次。

● 一次读一行和一次读多行是混合出现的。
 
● 一般来说，写每次只影响一行。



这就是很多人称之为的“事务型”负荷。这看起来很正常，但不要假设每个人的负荷都这样。例如，分析负荷通常都是批量插入，很少或没有更新，以及每次都涉及到整个表的大量读。很多数据库都设计为能很好地处理这种负荷，因为需要分析数据的业务往往都有海量的数据，而且在特别为数据分析做过优化的专有数据库上花了大笔的钱。

事务型负荷意味着，除非应用程序设计得很精巧，否则无法只做读取操作(这样设计是个好主意，但这是一个不同的话题)。从运维的角度来说，与一直在线的特点一样，这种事务型负荷也缩小了你的选择空间。

一个相关的方面是数据与查询的简单性。因为基础的数据模型通常都不复杂，所以多数Web应用都生成前述的事务型负荷。如果将典型Web应用的数据模型做上

一些处于中心位置的表通常少于10个。很多这种表都会存储类的数据，如用户，这些数据通常都是以一次一行的方式存取的。

网站的流量很大程度上决定了数据库的流量。用户浏览网站，就会在用户表中对该用户的那行记录进行读写。浏览网站一般都会导致应用程序读取数据集或数据区域来填充页面浏览也会潜在地显示一些统计数据，如你社会网络中的好友数，而要生成这些统计数据，就要做汇总或聚集查询。所以，查询通常会满足下面的模式:

● 读写用户表，一次一行。

● 以区域或集合方式读取用户自己的数据。以区域或集合方式读取其他用户的数据。
 
● 从该用户与其他用户的关联表中读取区域行(ranges of rows)。对该用户和其他用户的数据进行汇总与计数。

行的区域与集合通常是由某些条件将结果限制为前N个(topN)的SQL查询，如最新记录。这些结果常常是分页的，所以查询条件会是一个偏移量和一个记录条数的组合。不同的网站建设数据库会用不同的方式来做这样的查询，所以我就不展示具体的查询例子了。