数据库设计--垂直拆分数据

假设表字段太多,假设表中有些字段比較大,即便是你仅仅查有限的几个字段。在做表关联和全表扫的时候,由于扫描的数据块多,性能方面还是会不理想。由于oracle扫描的时候是依照块为单位扫描,读取的时候也是按块为单位读取。所以这样的功能无法在SQL层面上优化的时候。能够考虑做数据的垂直切分。以下来做个试验:

--制造数据不做垂直切分

create table test(

a number,

b varchar2(4000),

c varchar2(4000),

d varchar2(4000),

e varchar2(4000),

f varchar2(4000),

g varchar2(4000),

h varchar2(4000)

);

INSERT INTO test

SELECT ROWNUM,

rpad(‘*‘, 4000, 1),

rpad(‘*‘, 4000, 1),

rpad(‘*‘, 4000, 1),

rpad(‘*‘, 4000, 1),

rpad(‘*‘, 4000, 1),

rpad(‘*‘, 4000, 1),

rpad(‘*‘, 4000, 1)

FROM DUAL

CONNECT BY ROWNUM <= 100000;

commit;

create table test1 as select * from  test;

--制造数据做垂直切分

create table test_cuizhi(

a number

);

INSERT INTO test_cuizhi

SELECT ROWNUM

FROM DUAL

CONNECT BY ROWNUM <= 100000;

commit;

create table test_cuizhi1 as select * from  test_cuizhi;

--開始測试,仅仅是取两个最小的字段

SQL> set timing on

SQL> set autotrace traceonly

SQL> select t.a,t1.a from test t, test1  t1 where t.a=t1.a;

已选择100000行。

已用时间:  00: 00: 53.17

运行计划

----------------------------------------------------------

Plan hash value: 2400077556

----------------------------------------------------------------------------

| Id  | Operation          | Name  | Rows  | Bytes | Cost (%CPU)| Time     |

----------------------------------------------------------------------------

|   0 | SELECT STATEMENT   |       | 44504 |  1129K|   173K  (1)| 00:34:38 |

|*  1 |  HASH JOIN         |       | 44504 |  1129K|   173K  (1)| 00:34:38 |

|   2 |   TABLE ACCESS FULL| TEST  | 44504 |   564K| 87801   (1)| 00:17:34 |

|   3 |   TABLE ACCESS FULL| TEST1 |   117K|  1490K| 85344   (1)| 00:17:05 |

----------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - access("T"."A"="T1"."A")

Note

-----

- dynamic sampling used for this statement

统计信息

----------------------------------------------------------

52  recursive calls

0  db block gets

795627  consistent gets

534917  physical reads

0  redo size

1664840  bytes sent via SQL*Net to client

73664  bytes received via SQL*Net from client

6668  SQL*Net roundtrips to/from client

2  sorts (memory)

0  sorts (disk)

100000  rows processed

SQL> /

已选择100000行。

已用时间:  00: 00: 33.36

运行计划

----------------------------------------------------------

Plan hash value: 2400077556

----------------------------------------------------------------------------

| Id  | Operation          | Name  | Rows  | Bytes | Cost (%CPU)| Time     |

----------------------------------------------------------------------------

|   0 | SELECT STATEMENT   |       | 44504 |  1129K|   173K  (1)| 00:34:38 |

|*  1 |  HASH JOIN         |       | 44504 |  1129K|   173K  (1)| 00:34:38 |

|   2 |   TABLE ACCESS FULL| TEST  | 44504 |   564K| 87801   (1)| 00:17:34 |

|   3 |   TABLE ACCESS FULL| TEST1 |   117K|  1490K| 85344   (1)| 00:17:05 |

----------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - access("T"."A"="T1"."A")

Note

-----

- dynamic sampling used for this statement

统计信息

----------------------------------------------------------

0  recursive calls

0  db block gets

795446  consistent gets

552087  physical reads

0  redo size

1664840  bytes sent via SQL*Net to client

73664  bytes received via SQL*Net from client

6668  SQL*Net roundtrips to/from client

0  sorts (memory)

0  sorts (disk)

100000  rows processed

SQL> select t.a,t1.a from test_cuizhi t, test_cuizhi1  t1 where t.a=t1.a;

已选择100000行。

已用时间:  00: 00: 06.17

运行计划

----------------------------------------------------------

Plan hash value: 2501302817

-------------------------------------------------------------------------------------------

| Id  | Operation          | Name         | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |

-------------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT   |              | 88629 |  2250K|       |   310   (2)| 00:00:04 |

|*  1 |  HASH JOIN         |              | 88629 |  2250K|  2168K|   310   (2)| 00:00:04 |

|   2 |   TABLE ACCESS FULL| TEST_CUIZHI  | 88629 |  1125K|       |    42   (3)| 00:00:01 |

|   3 |   TABLE ACCESS FULL| TEST_CUIZHI1 |   101K|  1288K|       |    39   (3)| 00:00:01 |

-------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - access("T"."A"="T1"."A")

Note

-----

- dynamic sampling used for this statement

统计信息

----------------------------------------------------------

52  recursive calls

0  db block gets

7139  consistent gets

153  physical reads

0  redo size

1664840  bytes sent via SQL*Net to client

73664  bytes received via SQL*Net from client

6668  SQL*Net roundtrips to/from client

2  sorts (memory)

0  sorts (disk)

100000  rows processed

SQL> /

已选择100000行。

已用时间:  00: 00: 06.06

运行计划

----------------------------------------------------------

Plan hash value: 2501302817

-------------------------------------------------------------------------------------------

| Id  | Operation          | Name         | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |

-------------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT   |              | 88629 |  2250K|       |   310   (2)| 00:00:04 |

|*  1 |  HASH JOIN         |              | 88629 |  2250K|  2168K|   310   (2)| 00:00:04 |

|   2 |   TABLE ACCESS FULL| TEST_CUIZHI  | 88629 |  1125K|       |    42   (3)| 00:00:01 |

|   3 |   TABLE ACCESS FULL| TEST_CUIZHI1 |   101K|  1288K|       |    39   (3)| 00:00:01 |

-------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - access("T"."A"="T1"."A")

Note

-----

- dynamic sampling used for this statement

统计信息

----------------------------------------------------------

0  recursive calls

0  db block gets

7008  consistent gets

0  physical reads

0  redo size

1664840  bytes sent via SQL*Net to client

73664  bytes received via SQL*Net from client

6668  SQL*Net roundtrips to/from client

0  sorts (memory)

0  sorts (disk)

100000  rows processed

版权声明:本文博客原创文章,博客,未经同意,不得转载。

时间: 2024-10-12 23:00:00

数据库设计--垂直拆分数据的相关文章

学生成绩数据库设计 三 模拟数据

1 基础数据 1 /*一 模拟数据说明:从2000年到当年,每年添加100个学生*/ 2 Declare @StuCount int, /*每年添加的数量*/ 3 @StartYear int,/*初始年份*/ 4 @CurYear int /*当前年份*/ 5 Begin 6 /*设置添加数据的初始值*/ 7 SET @StuCount=100 8 SET @StartYear=2010 9 SET @CurYear=YEAR(GETDATE()) 10 11 /*1 向学年表添加数据*/ 1

数据仓库数据库设计方法---关系模型和多维模型比较分析

数据仓库中广泛采用的数据库设计模型有两种:关系型和多维型.普遍认为在数据仓库的设计方法中关系模型是“Inmon”方法而多维模型是“Kimball”方法. 先来看下关系模型,关系型数据以一种称为“标准化”的形式存在.数据标准化是指数据库设计会使数据分解成非常低的粒度级,标准化数据以一种孤立模式 存在,这种情况下对数据表里的数据关系要求很严格.一般遵循3NF范式.采用关系型设计的数据库一般具有较强的灵活性和多功能性(可以支持数据的多种视 图). 再来看下多维模型,多维模型一般有星型模式.雪花模式.混

噪声收集系统——数据库设计心得

数据库设计心得 在需求分析阶段,其实数据库的设计就已经初具雏形,组内初步分析了需要哪些表来存放哪类数据,并探讨了各个表中的关键字段.但在需求分析阶段的数据库设计并不完整,只描述了部分实体,表中的属性也不能完全描述需求,数据库表间的关系没有体现,这就需要进入详细的数据库设计阶段来完善. 在数据库设计的第一阶段,还是围绕用户需求来展开工作.用户的需求在设计过程中扮演着中心角色,如果一开始对需求的分析就出现偏差,那数据库设计就很容易出现问题,好在需求分析阶段结束后我们的需求是十分明确的,项目组内根据项

DAY87-BBS项目(一) 数据库设计与简单登陆、验证码

一.BBS项目之项目分析 项目流程: 1 搞清楚需求(产品经理) (1) 基于用户认证组件和Ajax实现登录验证(图片验证码) (2) 基于forms组件和Ajax实现注册功能 (3) 设计系统首页(文章列表渲染) (4) 设计个人站点页面---跨表查询,分组查询 (5) 文章详情页 (6) 实现文章点赞功能 (7) 实现文章的评论 ---文章的评论 ---评论的评论 (8) 副文本编辑框 和 防止xss攻击(防止别人提交js代码) 2 设计表结构 3 按着每一个功能分别进行开发 4 功能测试

数据库设计--数据的垂直拆分

如果表字段太多,如果表中有些字段比较大,即便是你只查有限的几个字段,在做表关联和全表扫的时候,由于扫描的数据块多,性能方面还是会不理想.因为oracle扫描的时候是按照块为单位扫描,读取的时候也是按块为单位读取,所以这种功能无法在SQL层面上优化的时候,可以考虑做数据的垂直切分,下面来做个试验: --制造数据不做垂直切分 create table test( a number, b varchar2(4000), c varchar2(4000), d varchar2(4000), e var

数据库垂直拆分,水平拆分利器,cobar升级版mycat

1,关于Mycat Mycat情报 基于阿里的开源cobar ,可以用于生产系统中,目前在做如下的一些改进: 非阻塞IO的实现,相对于目前的cobar,并发性能大大提升,而且不会陷入假死状态 优化线程池的分配,目前cobar的线程池分配效率不高 修复cobar一些BUG 参考impala中的impala front部分的Java代码,实现高效的Map-Reduce,能够处理上亿的大数据量 实现自动分片特性,目前cobar需要手工分片,并有一定的编程限制 官方网站: https://github.

数据库垂直拆分,水平拆分利器,cobar升级版mycat(转)

原文:数据库垂直拆分,水平拆分利器,cobar升级版mycat 1,关于Mycat Mycat情报 基于阿里的开源cobar ,可以用于生产系统中,目前在做如下的一些改进: 非阻塞IO的实现,相对于目前的cobar,并发性能大大提升,而且不会陷入假死状态 优化线程池的分配,目前cobar的线程池分配效率不高 修复cobar一些BUG 参考impala中的impala front部分的Java代码,实现高效的Map-Reduce,能够处理上亿的大数据量 实现自动分片特性,目前cobar需要手工分片

数据库优化-水平拆分 垂直拆分

过某种特定的条件,将存放在同一个数据库中的数据分散存放到多个数据库上,实现分布存储,通过路由规则路由访问特定的数据库,这样一来每次访问面对的就不是单台服务器了,而是N台服务器,这样就可以降低单台机器的负载压力.提示:sqlserver 2005版本之后,可以友好的支持“表分区”. 垂直(纵向)拆分:是指按功能模块拆分,比如分为订单库.商品库.用户库...这种方式多个数据库之间的表结构不同. 水平(横向)拆分:将同一个表的数据进行分块保存到不同的数据库中,这些数据库中的表结构完全相同. ▲(纵向拆

一分钟掌握数据库垂直拆分

一.缘起 当数据库的数据量非常大时,水平切分和垂直拆分是两种常见的降低数据库大小,提升性能的方法.假设有用户表: user( uid bigint, name varchar(16), pass varchar(16), age int, sex tinyint, flag tinyint, sign varchar(64), intro varchar(256) -); 水平切分是指,以某个字段为依据(例如uid),按照一定规则(例如取模),将一个库(表)上的数据拆分到多个库(表)上,以降低单