insert的不同场景性能比较(97天)

关于Insert的问题,可能在一些场景中会有完全不同的期望和结果,在日常工作使用的库中,需要表在Logging模式,必要时需要一些索引

但在数据迁移中,可能为了提高速度,索引就需要考虑重建了。

我做了一些场景的测试,并且做了详细的数据比对。

第一种场景:table在nologging模式下。并且表中没有索引,

在插入不同数据量的时候,生成的redo和响应时间都有一定的幅度提升。

比如插入13240331条记录时,响应时间为63秒,生成323219520bytes(300多M)的redo.

nologging+no index

sec:misec

inserted rows

redo generated

00.10

25862

635692

00.12

51723

1231620

00.18

103444

2461540

00.33

206885

4922516

00.67

413766

9840892

02.19

827527

19697976

09.90

1655048

40128988

15.68

3310089

80470212

33.89

6620170

161501892

63.28

13240331

323219520

第二种场景:table在logging模式下,表中没有索引

logging+no index

00.10

25862

635616

00.10

51723

1231620

00.17

103444

2461480

00.35

206885

4930208

00.68

413766

9841248

01.69

827527

19692980

06.94

1655048

40117876

16.66

3310089

80428640

41.23

6620170

161690412

72.47

13240331

323049996

总结:可以看到两者基本上没有任何变化

第三种场景:表在nologging模式,表中有主键,主键对应的索引处于logging模式

nologging+index(unique index) logging

00.22

25862

1381736

00.32

51723

2733468

00.44

103444

5431700

01.15

206885

10872316

03.25

413766

21777088

07.69

827527

43521600

16.33

1655048

90658812

41.71

3310089

183135576

82.40

6620170

366262424

190.50

13240331

731534236

可能直接看不太明显,如果有一个图标就更清晰了。左边的部分是采用logging,没有索引的场景,可以看到已经有了成倍的变化。可见在有索引的时候对于insert来说,会产生大量的redo,响应时间也成倍提高。

第四种场景,表采用nologging模式,表中无索引,使用append模式插入数据。

nologging+no index+append

00.14

25862

635632

00.14

51723

1231560

00.16

103444

2461480

00.33

206885

4922516

00.64

413766

9840848

01.52

827527

19697592

11.30

1655048

40165208

19.18

3310089

80450796

46.26

6620170

160910172

76.66

13240331

322991832

总结:可以看到在没有索引的情况下,nologging+append模式和nologging基本没有区别。

第五种场景:表处于nologging模式,表中有索引,处于Nologging模式。采用append插入数据。

可以看到采用index的logging和nologging模式,两者也没有明显的变化

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2014-06-08

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Python

MySQL常见的库操作,表操作,数据操作集锦及一些注意事项

一 库操作(文件夹) 1 数据库命名规则 可以由字母、数字、下划线、@、#、$ 区分大小写 唯一性 不能使用关键字如 create select 不能单独使用数...

2259
来自专栏Netkiller

数据库进程间通信解决方案IPC

数据库进程间通信解决方案 数据库与其他第三方应用程序进程间通信解决方案 摘要 你是否想过当数据库中的数据发生变化的时候出发某种操作?但因数据无法与其他进程通信...

3043
来自专栏Netkiller

数据库进程间通信解决方案

数据库进程间通信解决方案 数据库与其他第三方应用程序进程间通信解决方案 摘要 你是否想过当数据库中的数据发生变化的时候出发某种操作?但因数据无法与其他进程通信(...

3776
来自专栏蓝天

高性能高可用的分布式唯一ID服务——mooon-uniq-id

源码位置:https://github.com/eyjian/mooon/tree/master/application/uniq_id。

662
来自专栏自由而无用的灵魂的碎碎念

Oracle:创建db_link

global_name也就是数据库的全局数据库名,可已使用select * from global_name;查询:

822
来自专栏逸鹏说道

解决session阻塞的问题

简介 对于数据库运维人员来说创建session或者查询时产生问题是常规情况,下面介绍一种很有效且不借助第三方工具的方式来解决类似问题。 最近开始接触运维...

3426
来自专栏沃趣科技

MySQL中的统计信息相关参数介绍

统计信息的作用 上周同事在客户现场遇到了由于统计信息的原因,导致应用数据迁移时间过慢,整个迁移差点失败。关键时刻同事发现测试环境与生产环境SQL语句执行计划不一...

34110
来自专栏乐沙弥的世界

MyCAT全局表描述及示例

1131
来自专栏james大数据架构

微软官方提供的用于监控MS SQL Server运行状况的工具及SQL语句

Microsoft SQL Server 2005 提供了一些工具来监控数据库。方法之一是动态管理视图。动态管理视图 (DMV) 和动态管理函数 (DMF) 返...

2337
来自专栏idba

漫谈死锁

一 前言 死锁是每个MySQL DBA 都会遇到的技术问题,本文是自己针对死锁学习的一个总结,了解死锁是什么,MySQL如何检测死锁,处理死锁,死锁的案例,...

1164

扫码关注云+社区