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

如果表字段太多，如果表中有些字段比较大，即便是你只查有限的几个字段，在做表关联和全表扫的时候，由于扫描的数据块多，性能方面还是会不理想。因为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)

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

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

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

| 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

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

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

| 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

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

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

| 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

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

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

| 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

数据库设计--数据的垂直拆分,布布扣,bubuko.com

时间： 2024-10-22 02:28:18

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

数据建模和数据库设计

http://blog.csdn.net/suwu150/article/details/52724937 数据建模和数据库设计一. 实体-关系图实体-关系图(Entity Relationship Diagram),也称为E-R图,提供了表示实体.属性和关系的方法,用来描述现实世界的概念模型. 构成E-R图的基本要素是实体.属性和关系实体(Entity):实体用来表示具有相同特征和性质的事物(类似于java的类),实体由实体名和

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

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

数据库垂直拆分，水平拆分利器，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),按照一定规则(例如取模),将一个库(表)上的数据拆分到多个库(表)上,以降低单

数据库水平拆分和垂直拆分区别（以mysql为例）

数据库水平拆分和垂直拆分区别(以mysql为例) 案例: 简单购物系统暂设涉及如下表: 1.产品表(数据量10w,稳定) 2.订单表(数据量200w,且有增长趋势) 3.用户表 (数据量100w,且有增长趋势) 以mysql为例讲述下水平拆分和垂直拆分,mysql能容忍的数量级在百万静态数据可以到千万垂直拆分: 解决问题: 表与表之间的io竞争不解决问题: 单表中数据量增长出现的压力方案: 把产品表和用户表放到一个server上订单表单独放到一个server上水平拆分: 解决问题: 单

关于数据库表的水平拆分和垂直拆分

垂直拆分垂直拆分是指数据表列的拆分,把一张列比较多的表拆分为多张表通常我们按以下原则进行垂直拆分: 把不常用的字段单独放在一张表; 把text,blob等大字段拆分出来放在附表中; 经常组合查询的列放在一张表中; 垂直拆分更多时候就应该在数据表设计之初就执行的步骤,然后查询的时候用jion关键起来即可; 水平拆分水平拆分是指数据表行的拆分,表的行数超过200万行时,就会变慢,这时可以把一张的表的数据拆成多张表来存放. 水平拆分的一些技巧 1. 拆分原则通常情况下,我们使用取模的方式来进行

mysql关于数据库表的水平拆分和垂直拆分

最初知道水平垂直分表的时候是刚参加工作不久的时候,知道了这个概念,但是公司用户量和数据量始终没上来,所以也没用到过,知道有一天到了一家新公司后,这些才被应用到实际开发中,这里我就大概说说关于水平和垂直的拆分. 分表的概念还是比较好理解的,就拿本网站的评论表展开讲讲,源于数据量较大,当评论表有CURD操作时,单张表表现的可能有些力不从心,当然这里还能引申出关于读写速度的其他好多概念:数据库读写分离,NoSql等等. 垂直拆分:顾名思义是将表垂直着给拆掉,即:(下面是省略掉字段的一个表) +----