删除和更新操作的开销往往比插入高,所以一个好的设计需要减少对数据库的更新和删除操作。
3.1更新操作
数据库的更新操作会带来一连串的“效应”:更新操作需要记录日志(以便错误时回滚);更新可变长字段(如,varchar类型)会带来数据物理存储的变化(记录的移动);更新索引字段会导致索引重建;更新主键会导致数据重组等。这一切不但会造成更新操作本身效率低,而且由于磁片碎片的产生会造成以后查询性能的降低。为了应对这一情况,有两种策略:一、减少更新次数,把多个字段的更新写到同一个语句里;二、避免更新。这两种策略分别适用于不同的情况,下面将举例说明两种情况。
3.1.1减少更新次数
在整合库里有个代码清洗过程,就是通过连接代码表给业务数据的自编码字段赋值。代码清洗其实是通过关联代码表来更新业务数据表的一个过程,需要连接多个代码表,更新多个自编码字段。完成此更新,有两种更新语句的写法:一种是写成多个SQL语句,每个语句更新一个自编码字段;另一种写法是将所有更新写在一个语句中。更新银行代码的更新语句如下所示:
updateTBL_INCOME_TMP A setBANKCODESELF = ( select SELFCODE from TBL_BANKINFO B where A.BANKCODE = B.BANKCODE )
通过一个更新语句实现多个自编码字段更新的语句示意如下:
updateTBL_INCOME_TMP
set 代码1自编码 = 通过关联代码1表得到自编码,
代码2自编码 =通过关联代码2表得到自编码,
...,
代码n自编码 =通过关联代码n表得到自编码
利用两千万的测试数据。两种方法的测试结果如下表所示。从测试结果看出,一次更新方法性能提高了十倍,大大提高了性能。
处理过程
多次更新方法耗时
一次更新方法耗时
代码清洗
0:29:48
0:02:59
3.1.2避免更新
下面举个通俗的例子,这类情况是经常遇到的。某公司有一套系统员工考勤系统,为了提高查询统计的性能,在原有系统基础上建立了一些包含冗余信息的表。以员工表为例,它获得数据的过程如图12所示。第一步把员工信息放到新表中,然后连接通过字段“部门ID”连接更新“部门名称”。
图12. 关联更新
一般,为了节省存储开支把部门名称这样的字段设计成可变长的。所以在对它进行更新时会造成磁盘数据的重新组织,形成磁盘碎片,影响查询性能。
为了避免这样的情况发生,我们可以使用如图13所示的方法避免更新。这种方法一步完成了冗余数据表的插入,再插入时连接部门表获得“部门名称”,从而避免了更新操作。
图13. 避免更新
3.2删除操作
初学者可能认为删除操作很简单,可以快速完成。其实这是一个错误的理解,删除过程需要大量扫描磁盘;需要记录数据库日志;而且删除过程不释放磁盘空间,浪费磁盘,并且使磁盘上的数据支离破碎,这对后续查询的性能是一个致命的打击。通常用两种方式来应对:一、对经常做删除操作的表进行重组(reorg);二、避免删除。
3.2.1 重组
重组(reorg)操作会重新排列表数据的物理顺序,并除去碎片数据中的空闲空间。
由于删除操作不释放磁盘空间,在执行删除操作后,表会成为碎片状,这导致性能严重下降,在多次更新操作之后也会出现这种情况。若收集了统计信息,但看不出有明显的性能改进,则重组表数据可能会有帮助。重组表数据时,根据指定的索引重新安排数据的物理顺序,并除去碎片数据中的空闲空间。这使该数据可以更快速的被存取,从而改进性能。
3.2.2 避免删除——中间表和正式表模式
在数据需要比较复杂的处理的时候经常会用到中间表和正式表模式。数据在中间表中被处理,然后把满足条件的数据转移至正式表,不满足条件的数据保留在中间表中。图14示意了数据从中间表转移到正式表的过程:在完成数据处理之后,需要把中间表temp1中flag = 1的数据插入到正式表,并删除中间表temp1中flag = 1的数据。
图14. 从中间表向正式表转移数据
因为flag字段不是聚簇索引,所以当对中间表temp1进行删除后,会再磁盘中留下大量碎片,如图15所示。不但会留下那么多的磁盘碎片,而且已删除的数据的空间也不会自动释放。结果是不但浪费磁盘空间,而且查询性能会急剧下降。
图15. 删除操作后的磁盘碎片
咱们可以使用清空表的命令来避免删除操作。除了中间表temp1和正式表,添加辅助临时表temp2。如果temp1中保留的数据flag=0只占有10%,这一优化将显著提升性能。具体步骤如下:
1. 将temp1中flag=0的数据,插入到temp2
2. 清空表temp1
alter table temp1 ACTIVATE NOT LOGGED INITIALLY WITH EMPTY TABLE ;
3. 将temp2中的数据插入temp1
3.3如何使访问更高效
本小节的内容很大一部分来自《The Art of SQL》这本书,这本书里集合了数据库开发的通用经验。虽然没有局限于具体的DBMS和硬件平台,但是却是一本实践性很强的书。
1.一次连接数据库,做很多事情。直到处理完,才断开连接。
2.一个SQL语句包含尽量多的操作。形象地说:几千个语句,借助游标不断循环,很慢。换成几个语句,处理同样的数据,还是很慢。换成一个语句,解决问题,最好。
3.接近DBMS核心。尽量使用数据库自带的函数。减少自定义函数。因为再聪明的数据库优化器也不认识自定义函数。
4.一个语句不要连接太多的表,建议的上限是5个。
5.将频繁更新的列集中起来:当更新某一行时,DB2 会记录进行更改的所有列,因此将频繁更新的列放到一起可以减少 DB2 的记录工作。这只是一个有关性能的小建议,因此不应为实现它而进行重大的应用程序或数据库设计修改。
以上就是本文针对MySql删除和更新对性能有影响吗的全部内容,希望喜欢。
我想更新/删除OWL类中的公理(例如SubclassOf axioms)。 我有以下两种方法: 1)删除所有旧公理,然后创建所有新公理。 我想用-
问题内容: 我正在研究Java-8中引入的新添加的现有功能。新添加到String类的一个简单功能对我来说很有吸引力-即String Join方法 。 例: 出于好奇,我已经通过编写简单的Java代码检查了此功能的性能(执行时间) 结果对我来说并不那么令人兴奋(以秒为单位的时间) 复杂度为o(n)–实际上为(n *单个元素长度的大小) 我没有测量过的其他性能指标(内存等)。 我的问题是: 我的测量有
问题内容: 我有这个JavaWeb应用程序,它可以从电子表格上传成千上万的数据,该电子表格是从上到下按行读取的。我用来在服务器端显示应用程序当前正在读取的行。 -我知道要创建一个日志文件。实际上,我正在创建一个日志文件,同时在服务器提示符下显示日志。 还有其他方法可以在提示上打印当前数据? 问题答案: 它可能会影响您的应用程序性能。大小会因您所运行的硬件类型和主机上的负载而异。 可以将其转化为性能
前言 HTTPS 在保护用户隐私,防止流量劫持方面发挥着非常关键的作用,但与此同时,HTTPS 也会降低用户访问速度,增加网站服务器的计算资源消耗。 本文主要介绍 https 对用户体验的影响。 HTTPS 对访问速度的影响 在介绍速度优化策略之前,先来看下 HTTPS 对速度有什么影响。影响主要来自两方面: 协议交互所增加的网络 RTT(round trip time)。 加解密相关的计算耗时。
我运行Http服务器使用Netty I/O库在四核Linux机器上。使用默认工作线程池大小(在Netty中内部设置为2 x内核数)运行时,性能分析显示吞吐量上限为1k请求/秒,请求速率的进一步增加导致延迟几乎线性增加。 由于最大CPU利用率显示为60%,我根据下面的代码增加了工作线程的数量。然而,性能几乎没有任何变化,CPU仍然限制在60-70%。该进程不受内存、I/O或网络带宽的限制。为什么不通
问题内容: 我试图在接收每月数百万次页面浏览量的页面中找到一些简单的客户端性能调整。我关心的一个问题是使用CSS通用选择器()。 例如,考虑一个非常简单的HTML文档,如下所示: 通用选择器会将以上声明应用于,和元素,因为它们是文档中唯一的那些。 通常,我会从以下规则中看到更好的性能: 还是会产生完全相同的净效果? 通用选择器是否执行我可能不知道的更多工作? 我意识到该示例中的性能影响可能很小,但