工作有个给某表某字段添加一段文本的SQL,目的是隐藏用户信息,因表达两千万行耗时较多,当时觉得设上固定值效率会更高,于是有了下面的比较。
先确认下要进行实验的表规模:
SQL> select count(*) from tb_qianwan_final; COUNT(*) ---------- 16000000
一千六百万行,和实际中用表达到了同一等级。
把oracle的时间统计打开并查看表的字段:
SQL> set timing on; SQL> desc tb_qianwan_final; 名称 是否为空? 类型 ----------------------------------------- -------- ---------------------------- ID NOT NULL NUMBER(9) NAME NVARCHAR2(20) SALARY NUMBER(6) REMARK NVARCHAR2(60)
先对表进行修改:
SQL> update tb_qianwan_final set name=name||'end' where name is not null; update tb_qianwan_final set name=name||'end' where name is not null * 第 1 行出现错误: ORA-12899: 列 "UFO"."TB_QIANWAN_FINAL"."NAME" 的值太大 (实际值: 21, 最大值: 20)
原来是超过字段长度限制了,增长一下吧:
SQL> alter table tb_qianwan_final modify (name nvarchar2(24)); 表已更改。 已用时间: 00: 00: 00.23
看,修改字段定义的时间是秒出,和表规模无关。我现在有了个基本猜想,就是ddl和表规模无关,dml和select才相关。
接下来进行附加文本的update:
SQL> update tb_qianwan_final set name=name||'end' where name is not null; 已更新16000000行。 已用时间: 00: 19: 22.77
等了近二十分钟,够看三部阿斗了。
再实验统一文本的update:
SQL> update tb_qianwan_final set name='default' where name is not null; 已更新16000000行。 已用时间: 00: 07: 10.27
七分钟,只是附件文本方案的三分之一,统一文本方案胜出。
究其原因,还是附加方案把字段值取出来又设置回去,自然没有直接设置进去快了。
在增删改查里,取完了设,查中查,都是低效率之源。
要知道这大表的来源,请参考:https://www.cnblogs.com/xiandedanteng/p/12316854.html
我的环境:
# | 类别 | 版本 |
1 | 操作系统 | Win10 |
2 | 数据库 | Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production |
3 | 硬件环境 | T440p |
4 | 内存 | 8G |
--2020年2月22日--