其实不需要拆分表,分区就可以,还是原来的表名,只是将原来的表分成了若干的分区,这样能起到分表的效果,还不用分成很多的表。
比如你原来的表的名字是A,那么将该表改为A1,然后从新建立一个分区表A,分区的依据是班级,也就是list分区,也就是一般意义上的列表分区表。
然后再将A1的数据插入新A表就可以了。
至于分区表的建立方式,往上很多,可以自行查找。
这样 *** 作查询的语句不需要变,只是在不跨分区查询的情况下,相当于分成了若干张表去查询。比如查询1班的成绩,那么就是在1班的分区内,不会有2班的问题,就相当于你用一个指头就能解决问题,不会动用这个手一样。
如果分表的话,那么假设有12个班,那么就要建立12张表,这样的话,语句就要写12次,冗余太大了。
个人的观点,这种大表的优化,不一定上来就要分库分表,因为表一旦被拆分,开发、运维的复杂度会直线上升,而大多数公司是欠缺这种能力的。所以MySQL中几百万甚至小几千万的表,先考虑做单表的优化。
单表优化
单表优化可以从这几个角度出发:
表分区:MySQL在51之后才有的,可以看做是水平拆分,分区表需要在建表的需要加上分区参数,用户需要在建表的时候加上分区参数;分区表底层由多个物理子表组成,但是对于代码来说,分区表是透明的;SQL中的条件中最好能带上分区条件的列,这样可以定位到少量的分区上,否则就会扫描全部分区。
读写分离:最常用的优化手段,写主库读从库;
增加缓存:主要的思想就是减少对数据库的访问,缓存可以在整个架构中的很多地方,比如:数据库本身有就缓存,客户端缓存,数据库访问层对SQL语句的缓存,应用程序内的缓存,第三方缓存(如Redis等);
字段设计:单表不要有太多字段;VARCHAR的长度尽量只分配真正需要的空间;尽量使用TIMESTAMP而非DATETIME;避免使用NULL,可以通过设置默认值解决。
索引优化:索引不是越多越好,针对性地建立索引,索引会加速查询,但是对新增、修改、删除会造成一定的影响;值域很少的字段不适合建索引;尽量不用UNIQUE,不要设置外键,由程序保证;
SQL优化:尽量使用索引,也要保证不要因为错误的写法导致索引失效;比如:避免前导模糊查询,避免隐式转换,避免等号左边做函数运算,in中的元素不宜过多等等;
NoSQL:有一些场景,可以抛弃MySQL等关系型数据库,拥抱NoSQL;比如:统计类、日志类、弱结构化的数据;事务要求低的场景。
表拆分
数据量进一步增大的时候,就不得不考虑表拆分的问题了:
垂直拆分:垂直拆分的意思就是把一个字段较多的表,拆分成多个字段较少的表;上文中也说过单表的字段不宜过多,如果初期的表结构设计的就很好,就不会有垂直拆分的问题了;一般来说,MySQL单表的字段最好不要超过二三十个。
水平拆分:就是我们常说的分库分表了;分表,解决了单表数据过大的问题,但是毕竟还在同一台数据库服务器上,所以IO、CPU、网络方面的压力,并不会得到彻底的缓解,这个可以通过分库来解决。水平拆分优点很明显,可以利用多台数据库服务器的资源,提高了系统的负载能力;缺点是逻辑会变得复杂,跨节点的数据关联性能差,维护难度大(特别是扩容的时候)。
希望我的回答,能够帮助到你!我将持续分享Java开发、架构设计、程序员职业发展等方面的见解。
数据库建表分区partitionbyid根据原理
Mysql 的分区技术与水平分表有点类似, 但是它是在逻辑层进行的水平分表, 对于应用而言它还是一张表, 换句话说: 分区不是实际真正的对一张表进行拆分,分区之后表还是一个表,它是把存储文件进行拆分。
在 Mysql 51(后) 有了几种分区类型:
RANGE分区: 基于属于一个给定连续区间的列值, 把多行分配给分区
LIST分区: 类似于按 RANGE 分区, 区别在于 LIST 分区是基于列值匹配一个离散值集合中的某个值来进行选择
HASH分区: 基于用户定义的表达式的返回值来进行选择分区, 该表达式使用将要插入到表中的这些行的列值进行计算, 这个函数可以包含 Mysql 中有效的、产生非负整数值的任何表达式
KEY分区: 累世于按 HASH 分区, 区别在于 KEY 分区只支持计算一列或多列, 且 Mysql 服务器提供其自身的哈希函数
create table xxx(id number,time date)
parttion by range(time)
(partion part1 values less than (to_date('2012-01-31','yyyy-mm-dd')) tablespace tb1,
partion part 2 vales less than(to_date('2012-01-31','yyyy-mm-dd')) tablespace tb2);
ql代码
#这里使用HASH表分区,mysql会根据HASH字段来自动分配数据到不同的表分区,这种情况适用于没有表分区规则但是有需要分表来进行查询优化的情况。这里根据id字段hash规则创建2个表分区
CREATE TABLE `creater_bak` (
`id` int(11) NOT NULL,
`name` varchar(100) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
PARTITION BY HASH(id) PARTITIONS 2
创建完成后开始导入原表数据:
Sql代码
insert into creater_bak select from creater;
导入以后的新表数据就是分布在不同的2个表分区中了。
如果数据量非常大,觉得预设的表分区数量太少,那么可以新增表分区,mysql会自动重新分配:
Sql代码
#这里新增8个表分区,加上新建表时候的2个,一共10个表分区了
ALTER TABLE `creater_bak` ADD PARTITION PA
个人认为理论上使用表分割在性能上应该和建立表分区查不多,但是,表分割对于所有的数据库都适用,而表分区只能用于oracle这样的特定的数据库;表分区属于数据库物理设计,表分割属于逻辑设计。
表分区:
表分区是ORACLE对于非常大的表进行优化的一种有效方法, 是非常有效的一种手段, 在很多情况下,比你说的表分割更有效,比如,有一个代码表,使用分区表把100万纪录分在10个分区中(ID 每从1到10万为一个分区),那样写查询语句的时候,只要给出查询条件中所需要的代码,ORACLE自动会定位到对应的分区进行查询,大大降低的查询时间 而采用表分割,那必须先根据查询的代码指定所要查询的表,才能找到相应的纪录 而且,如果有下面这样的语句,查询的条件是跨分区的:
SELECT FROM MYTABLE WHERE ID BETWEEN 99000 AND 10111;
在分区表中是非常容易实现的,ORACLE会自动在两个分区中查询;而采用表分割的话是否必须写成两个查询语句在UNION ALL。
事实上,大型的数据库都有对大表的特殊处理方式(类似于分区表),如果太强调可移植性而放弃这些最重要的特性的话,那性能很可能受到很大的影响
即便是oracle数据库,当数据量很大时,用分表比用表分区要快些,尤其是在表用到group by求和等 *** 作。
我也认为表分区要好一些,也就是一般说来的分区表,对这些表 *** 作起来有很多强大的功能,说他强大主要是体现在对与表中有海量数据的情况之下的,试问大家一个其中有1亿条记录的表你是否会经常的将其移植到其他数据库系统当中去呢?
表分区基于物理存储,还有就是基于分区的索引可以使用,很不错的,当然,这些都是在海量数据情况之下的比较,但是如果真要是数据量不大的情况下比较,我想要比较分区表和表分割就没什么意思了。
表分区的效果对硬件有所依赖,而且效果恐怕不如诸位想象中那么好。我做过一点测试,很失望。
而表分割的效率提升在很多时候(不是所有时候)是很明显的。
当然这都是在巨型表的前提下讨论,缩小表和索引的规模有利于提高效率,这正是分割表的特点。
表分割:
1、水平分割:根据一列或多列数据的值把数据行放到两个独立的表中。
水平分割通常在下面的情况下使用:A 表很大,分割后可以降低在查询时需要读的数据和索引的页数,同时也降低了索引的层数,提高查询速度。B 表中的数据本来就有独立性,例如表中分别记录各个地区的数据或不同时期的数据,特别是有些数据常用,而另外一些数据不常用。C需要把数据存放到多个介质上。
例如法规表law就可以分成两个表active-law和 inactive-law。activea-authors表中的内容是正生效的法规,是经常使用的,而inactive-law表则使已经作废的法规,不常被查询。水平分割会给应用增加复杂度,它通常在查询时需要多个表名,查询所有数据需要union *** 作。在许多数据库应用中,这种复杂性会超过它带来的优点,因为只要索引关键字不大,则在索引用于查询时,表中增加两到三倍数据量,查询时也就增加读一个索引层的磁盘次数。
2、垂直分割:把主码和一些列放到一个表,然后把主码和另外的列放到另一个表中。
如果一个表中某些列常用,而另外一些列不常用,则可以采用垂直分割,另外垂直分割可以使得数据行变小,一个数据页就能存放更多的数据,在查询时就会减少I/O 次数。其缺点是需要管理冗余列,查询所有数据需要join *** 作。
分区、分表、分库的详细理解
一、什么是分区、分表、分库
分区
就是把一张表的数据分成N个区块,在逻辑上看最终只是一张表,但底层是由N个物理区块组成的
分表
就是把一张表按一定的规则分解成N个具有独立存储空间的实体表。系统读写时需要根据定义好的规则得到对应的字表明,然后 *** 作它。
分库
一旦分表,一个库中的表会越来越多
将整个数据库比作图书馆,一张表就是一本书。当要在一本书中查找某项内容时,如果不分章节,查找的效率将会下降。而同理,在数据库中就是分区。
二、常用的单机数据库的瓶颈
问题描述
单个表数据量越大,读写锁,插入 *** 作重新建立索引效率越低。
单个库数据量太大(一个数据库数据量到就是极限)
单个数据库服务器压力过大
读写速度遇到瓶颈(并发量几百)
三、分区
什么时候考虑使用分区?
一张表的查询速度已经慢到影响使用的时候。
sql经过优化
数据量大
表中的数据是分段的
对数据的 *** 作往往只涉及一部分数据,而不是所有的数据
分区解决的问题
主要可以提升查询效率
分区的实现方式(简单)
mysql5 开始支持分区功能
四、分表
什么时候考虑分表?
一张表的查询速度已经慢到影响使用的时候。
sql经过优化
数据量大
当频繁插入或者联合查询时,速度变慢
分表解决的问题
分表后,单表的并发能力提高了,磁盘I/O性能也提高了,写 *** 作效率提高了
查询一次的时间短了
数据分布在不同的文件,磁盘I/O性能提高
读写锁影响的数据量变小
插入数据库需要重新建立索引的数据减少
分表的实现方式(复杂)
需要业务系统配合迁移升级,工作量较大
分区和分表的区别与联系
分区和分表的目的都是减少数据库的负担,提高表的增删改查效率。
分区只是一张表中的数据的存储位置发生改变,分表是将一张表分成多张表。
当访问量大,且表数据比较大时,两种方式可以互相配合使用。
当访问量不大,但表数据比较多时,可以只进行分区。
常见分区分表的规则策略(类似)
Range(范围)
Hash(哈希)
按照时间拆分
Hash之后按照分表个数取模
在认证库中保存数据库配置,就是建立一个DB,这个DB单独保存user_id到DB的映射关系
以上就是关于oracle数据库按照一定条件把表拆分为多个表全部的内容,包括:oracle数据库按照一定条件把表拆分为多个表、mysql数据库中,数据量很大的表,有什么优化方案么、数据库建表分区partitionbyid是根据什么原理等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)