修改表字段长度的操作,对业务是否有影响?

简介: 前两天测试同学问了一个问题,表中某一个字段,需要改一下长度,对业务是否会有影响?可能隐约之中,我们觉得没影响,但又好像有影响,究竟有何影响,我们从实验来看最科学。

前两天测试同学问了一个问题,表中某一个字段,需要改一下长度,对业务是否会有影响?


可能隐约之中,我们觉得没影响,但又好像有影响,究竟有何影响,我们从实验来看最科学。


首先建测试表,NAME字段是VARCHAR2(10),10个字节的字符串类型,表有256万数据。我们将其长度改为20,从执行时间看,只有20毫秒,



我们对上面的操作,做一下10046 trace,发现确实,首先使用LOCK以EXCLUSIVE模式锁定了TBL表,


接下来执行alter table修改操作,



从trace文件看,主要是针对一些数据字典表的操作,其中包含28次select,10次update,12次delete,可以想象一个改字段长度的操作,就有几十次SQL操作,但用时仅为毫秒级,效率可见一斑。


我们从alter table新增字段操作究竟有何影响?(下篇)的介绍,可以知道,EXCLUESIVE模式的锁,是最高级别的锁,Alter table,Drop table,Drop index,Truncate table这些常见的DDL操作,都会需要这种级别的锁,我们知道Oracle中select这种查询(不带for update)是不会有锁的,因此若表有EXCLUSIVE级别的锁时,仅允许select操作(不带for update),禁止其他类型的操作,

从锁的强弱看,EXCLUSIVE(exclusive,X)>SHARE ROW EXCLUSIVE(S/Row-X,SRX)>SHARE(Share,S)>ROW EXCLUSIVE(Row-X,RX)>ROW SHARE(Row-S,RS)。


最后,引述一篇博客的总结(http://blog.itpub.net/9252210/viewspace-626388/),

2级锁Row-S行共享(RS):共享表锁,sub share,锁有:Select for update,Lock For Update,Lock Row Share。

3级锁Row-X行独占(RX):用于行的修改,sub exclusive,锁有:Insert, Update, Delete, Lock Row Exclusive。

4级锁Share共享锁(S):阻止其他DML操作,share,锁有:Create Index, Lock Share,locked_mode为2,3,4不影响DML(insert,delete,update,select)操作, 但DDL(alter,drop等)操作会hang。

5级锁S/Row-X共享行独占(SRX):阻止其他事务操作,share/sub exclusive,锁有:Lock Share Row Exclusive,具体来讲有主外键约束时update / delete … ; 可能会产生4,5的锁。

6级锁exclusive 独占(X):独立访问使用,exclusive,锁有:Alter table, Drop table, Drop Index, Truncate table, Lock Exclusive。


因此,针对上面VARCHAR2(10)改为VARCHAR2(20)的操作,我们的结论是修改字段长度的操作是会阻碍其他非select操作,但是持续的时间很有限,几乎可以说是忽略不计,因为需要操作的是数据字典信息,并不是表自身,所以和要操作表的记录总量,没有任何关系。


无意之中,发现了另一个问题,将字段长度从VARCHAR2(20)改为VARCHAR2(10),用时比之前要久,540毫秒,几乎是之前的10倍,


我们看下他的trace,首先还是以EXCLUSIVE模式锁表,


接着执行alter table操作,


我们从下面的信息,看出了一些端倪,


以FIRST_ROWS优化器模式执行select操作,条件是字段NAME长度>10,因为现在是要将字段长度,从20改为10,就需要判断是否已存数据中,有违反长度的记录,如果有则禁止此操作,所以需要以全表扫描,来检索表中所有记录,rows是0,则继续执行其他操作,需要注意的是,他采用了FIRST_ROWS模式,会以最快的速度返回记录,因此执行时间还是可控的,从操作上来看,整个操作包含27次select,10次update,12次delete,其中判断LENGTH("NAME")>10的语句占用了几乎90%的SQL执行时间。


总结:

1. 若是增加长度的操作,会以EXCLUSIVE模式锁表,但其主要操作的是数据字典表,锁占用时间几乎可以忽略不计,所以几乎不会影响业务。

2. 若是缩短长度的操作,还会以EXCLUSIVE模式锁表,但需要以FIRST_ROWS优化器模式,执行全表扫描,判断已存数据是否有超长的记录,因此相比(1)执行时间会略久,但基本可控。



如果您觉得此篇文章对您有帮助,欢迎关注微信公众号:bisal的个人杂货铺,您的支持是对我最大的鼓励!共同学习,共同进步:)

目录
相关文章
|
2月前
|
分布式计算 DataWorks 数据处理
DataWork数据处理问题之属性覆盖掉如何解决
DataWork数据处理是指使用DataWorks平台进行数据开发、数据处理和数据治理的活动;本合集将涵盖DataWork数据处理的工作流程、工具使用和问题排查,帮助用户提高数据处理的效率和质量。
27 0
|
5月前
|
Java
策略枚举:消除在项目里大批量使用if-else的优雅姿势
可以替换大量的if-else语句,且具备较好的可读性与扩展性,同时能显得轻量化,我比较推荐使用策略枚举来消除if-else。
35 0
|
7月前
ookie 值的修改方案
ookie 值的修改方案
51 0
|
缓存 开发框架 .NET
实体列表缓存(最土的办法实现百万级性能)
在实际项目开发中,经常遇到有一些表数据很少(1000行以内),不会频繁修改(平均每行几个小时才会修改一次),例如配置表、分类表等。 这样的表,往往可以接受三五秒甚至更长的延迟,正是最适合使用缓存的地方。 实体缓存:一次性加载全表数据进入内存,供上层多维度查询!
207 0
|
SQL Oracle 关系型数据库
PostgreSQL 使用逻辑decode实现异步主从切换后,时间线分歧变化量补齐、修复
PostgreSQL 使用逻辑decode实现异步主从切换后,时间线分歧变化量补齐、修复
1285 0
|
Java Scala
slick对超过22个属性的表进行映射的两种办法
版权声明:本文为博主原创文章,未经博主允许不得转载 slick是scala的一个FRM(Functional Relational Mapper)框架,即函数式的关系数据库编程工具库。使用slick不同于使用java的hibernate或者是mybatis,对其进行迭代开发非常方便,因为其对表的映射基于函数式的编程方式。
1081 0

热门文章

最新文章