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 条评论
登录 后参与评论

相关文章

来自专栏Spark学习技巧

phoenix二级索引

二级索引 二级索引是从主键访问数据的正交方式。Hbase中有一个按照字典排序的主键Rowkey作为单一的索引。不按照Rowkey去读取记录都要遍历整张表,然后按...

85090
来自专栏idba

漫谈死锁

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

18040
来自专栏编程心路

语言小知识-MySQL数据库引擎

MySQL 作为全世界广受欢迎的数据库,被用于很多中小型的项目中,但是你对 MySQL 数据库的存储引擎了解多少呢?

14540
来自专栏数据和云

SQL优化误用'append'案例一则

编辑手记:SQL是数据库系统的核心,因SQL问题引发的系统蝴蝶效应屡见不鲜,今天继续学习SQL优化的技巧。。 这是某客户关键系统的一个TOP SQL: ? 根据...

349100
来自专栏乐沙弥的世界

MyCAT全局表描述及示例

18210
来自专栏Netkiller

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

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

35650
来自专栏蓝天

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

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

9220
来自专栏JMCui

SQL优化二(SQL性能调优)

一·、前言:这篇博文内容非原创,是我们公司的架构师给我们做技术培训的时候讲的内容,我稍微整理了下,借花献佛。这篇博文只是做一个大概的科普介绍,毕竟SQL优化的知...

43260
来自专栏

无锁队列的实现

锁是高性能程序的杀手,但是为了保证数据的一致性,在多线程的应用环境下又不得不加锁。但是在某些特殊的场景下, 是可以通过优化数据结构来达到无锁的目的。那么我们就来...

33960
来自专栏Netkiller

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

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

33430

扫码关注云+社区

领取腾讯云代金券