多半Web数据库都有人们称之为“高度事务型”的工作负荷，你也可能据说过这称为OLTP(在线事务处置)。这名字有点误导，因为这平日并不料味着正在运行金融事务，在SOL意义上甚至也不料味着是数据库事务。平日只是意味着运用法式做一些混杂着读写一些行或一些行集的工作罢了。许多互联网运用都匹配下面的模式。

● 运用法式读得多，读对写的比率规模从读五次写一次到读十次写一次不等，甚至一路飙升到读几百次オ写一次。

● 一次读一行和一次读多行是混杂涌现的。

● 一般来说，写每次只影响一行。

这就是许多人称之为的“事务型”负荷。这看起来很正常，但不要假设每小我的负荷都如许。例如，剖析负荷平日都是批量插入，很少或没有更新，以及每次都涉及到全部表的年夜量读。许多数据库都设计为能很好地处置这种负荷，因为须要剖析数据的营业往往都有海量的数据，并且在特殊为数据剖析做过优化的专稀有据库上花了年夜笔的钱。

事务型负荷意味着，除非运用法式设计得很精致，不然无法只做读取操作(如许设计是个好主张，但这是一个分歧的话题)。从运维的角度来说，与一向在线的特色一样，这种事务型负荷也缩小了你的选择空间。

一个相干的方面是数据与查询的简略性。因为基本的数据模子平日都不庞杂，所以多半Web运用都生成前述的事务型负荷。假如将典范Web运用的数据模子做上

一些处于中间地位的表平日少于10个。许多这种表都邑存储类的数据，如用户，这些数据平日都是以一次一行的方法存取的。

网站的流量很年夜水平上决议了数据库的流量。用户阅读网站，就会在用户表中对该用户的那行记载进行读写。阅读网站一般都邑导致运用法式读取数据集或数据区域来填充页面阅读也会潜在地显示一些统计数据，如你社会收集中的石友数，而要生成这些统计数据，就要做汇总或集合查询。所以，查询平日会知足下面的模式:

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

● 以区域或聚集方法读取用户本身的数据。以区域或聚集方法读取其他用户的数据。

● 从该用户与其他用户的联系关系表中读取区域行(rangesofrows)。对该用户和其他用户的数据进行汇总与计数。

行的区域与聚集平日是由某些前提将成果限制为前N个(topN)的SQL查询，如最新记载。这些成果经常是分页的，所以查询前提会是一个偏移量和一个记载条数的组合。分歧的网站扶植数据库会用分歧的方法来做如许的查询，所以我就不展现具体的查询例子了。