Mysql第八天 分区与分表
2015-07-21 17:25
513 查看
分区表
主要提供如下的特性,或者适合如此场景:数据量非常大, 或者只有表中最后的部分有热点数据,其他均为历史数据
分区表数据更容易维护,可以对独立的分区删除等操作
分区表的数据可以分布在不同的物理设备上,从而高效地利用多个硬件设备。
可以避免一些特殊瓶颈,比如InnoDB的单个索引的互斥访问
可以备份和恢复独立的分区
创建分区表
通常有这么几种分法,因为主键或者是唯一约束键必须有一部分包含在分区键中,所以一般要不无主键,要不就按照自增主键的id进行范围分区,要不就把分区字段和主键一起作为联合主键。还有一些其他的限制,比如分区键的运算结果必须为整数
Range分区
CREATE TABLE biz_order( id bigint(20) NOT NULL AUTO_INCREMENT, created DATETIME NOT NULL COMMENT '创建时间', PRIMARY KEY (id, created)) ENGINE=InnoDB PARTITION BY RANGE(YEAR(created))( PARTITION p_2010 VALUES LESS THAN (2015), PARTITION p_latest VALUES LESS THAN MAXVALUE);
这种分区,最新的那个区显然会有最多的热点数据。 可以再使用Hash子分区来减少竞争
- 除了使用YEAR, TO_DAY等日期函数外,还可以使用其数学函数,比如取模,按7取模是周几等
List分区
是用IN来做列值匹配的集合。 比如可以按照地区来分为东西南北几个区:PARTITION BY LIST(store_id) PARTITION pNorth VALUES IN (3,5,6,9,17), PARTITION pEast VALUES IN (1,2,10,11,19,20), PARTITION pWest VALUES IN (4,12,13,14,18), PARTITION pCentral VALUES IN (7,8,15,16) );
这种如果插入语句不在IN中,则会插入失败
Hash分区
PARTITIONS为分区的数量, 即会根据分区键的值计算出一个hash值,然后以4为模进行存储,好处是,不用再重新建分区了。PARTITION BY HASH(store_id) PARTITIONS 4;
还有Key分区,用的太少,不说了
操作分区表
增加删除分区等语句看这里分区表由多个底层表构成,底层表跟普通表没什么区别,其索引也是分别在各个表中的索引。 分区表只是会在一个很粗的粒度上决定一下去哪个底层表继续查询。
SELECT 锁住底层表,优化器先判断可以过滤部分的分期,然后再调用存储引擎接口访问各个分区
INSERT DELETE同行
UPDATE 操作会需要设计更新后判断在哪个分区,如果插入到了新分区,那么则删除原分区中的数据。
使用WHERE语句最好能够明确用到分区的关键字,这样可以很好的命中分区
锁住底层表不一定是表锁,会用到存储引擎自己的行级锁
如何使用
使用分区表肯定是因为数据量非常大,这个时候索引已经不能很好的起作用了。可以不使用索引,而用粗粒度的命中分区表,然后全表扫描。
或者是针对热点数据,单独使用一个区让这个区都能够放到缓存中,这样就会有一个热点的很小的分区,可以对其使用索引。
另外一些可能的问题:
NULL值,因为TO_DAY等方法NULL值为无效入参,会把值放在第一个分区,这个时候SELECT的时候可能会需要查找第一个和命中的分区这样两个分区,这样可能会有很多的性能损耗,解决办法是使第一个分区尽可能的小,第二个办法是直接使用RANGE COLUMNS()而不使用函数
分区列和索引列应该用同一个列,如果不是,会导致无法过滤的问题
寻找分区的成本可能会比较高
维护分区的成本,比如alter等语句改变分区个数,或者其他涉及数据迁移的操作
分区表的查询
要在WHERE后面带分区列,且不能是表达式使用EXPLAIN PARTITIONS SELECT来判断是否进行了分区过滤
分表
分区表还是一张表,是一种逻辑上的实现,主要解决的是单表数据过大,索引效率低的问题,很适合大量历史数据,少量活跃数据的场景。把数据保存在不同的区域。分表是真的有多张表,基于分表还可以做分库,可以提升并发性能,以及磁盘I/O的性能。
二者可以配合使用。
使用集群的方式
要配合复制使用,仅仅是把查询请求进行了分摊。但是这样不会影响代码层。
使用业务逻辑划分
可一个根据用户id来分,每个用户一张表,这样需要每有新的用户都建表了。还有常用的做法是预先设计好比如100张表,然后对数据的一个字段做hash,然后对100取模。
又或者根据时间来进行分割,这种的好处是,如果根据时间做统计的时候可以不用UNION
上面的分表方式都不能解决根据服务器压力进行选择的问你,并且也不能比较均匀的保存数据。
分表之后要考虑这样几个操作以后可能会带来的问题:
分页, 主要看分页情况下排序的字段是什么,如果是时间,那么按照时间段分表是比较好的, 如果会涉及到多个表的UNION,那么就会比较耗费性能。
插入, 更新。 主要是更新的时候的主键的问题,因为分表之后主键不唯一了,因此需要用分表列和自增列做联合主键。
分组,统计。 这个跟分页考虑的情况差不多,也是主要涉及排序的问题。比如如果每次都是需要按照用户统计信息的话,那么按照用户分表的选择是没错的。
表的分发跟业务很比较大的关系。要尽量考虑比较多的因素和场景。
通用一些的解决办法是,对分页字段使用搜索引擎
或者对分页和排序字段单独列一张表不分,作为查询的索引。
使用merge存储引擎
基本表: CREATE TABLE TEST_MERGE_1( ID INT(5) NOT NULL, VALUE VARCHAR(100) NOT NULL, PRIMARY KEY(ID) ); CREATE TABLE TEST_MERGE_2( ID INT(5) NOT NULL, VALUE VARCHAR(100) NOT NULL, PRIMARY KEY(ID) ); MERGE表: CREATE TABLE TEST_MERGE( ID INT(5) NOT NULL, VALUE VARCHAR(100) NOT NULL, PRIMARY KEY(ID) ) TYPE=MRG_MyISAM INSERT_METHOD=LAST UNION=(TEST_MERGE_1,TEST_MERGE_2);
基本表必须是MYISAM类型的。
基本表的数据结构必须一致。
order by等语句,我想的是因为Merge表里有基本表共同的索引,所以,排序的时候应该是,都先比较第一个,然后再。。。有点像常用的大文件分成多个小文件,然后分别排序,最后merge的过程。
主要是能够提供比较好的编码界面。
相关文章推荐
- hibernate连接mysql所需的jar包
- Mysql启动自动设置max_connections为其他值
- MySQL5.6.25安装教程
- Mysql 基于 Amoeba 的 读写分离
- Mysql字段类型以及操作
- 常用MySQL命令
- MySQL的基本数据类型与数据类型优化
- mysql中where字句的特殊用法
- 针对性的mysql 查询统计
- mysql基本知识
- Error code:1728 Cannot load from mysql.proc. The table is probably corrupted
- mysql取出指定id之外的所有数据
- MySQL 数据库改名的简单方法
- 每天进步一点点——mysql——Percona XtraBackup(innobackupex)
- InnoDB: Check that you do not already have another mysqld process 错误解决办法
- MySQL插入效率改进
- MySQL性能调优my.cnf详解
- Mysql存储过程_一次性建立多张表
- Entity Framework Code First ---EF Power Tool 和MySql一起使用遇到的问题
- mysql中表名为关键字的处理方法