MySQL优化之分区表

当数据库数据量涨到一定数量时,性能就成为我们不能不关注的问题,如何优化呢? 常用的方式不外乎那么几种:

  1、分表,即把一个很大的表达数据分到几个表中,这样每个表数据都不多。

    优点:提高并发量,减小锁的粒度
    缺点:代码维护成本高,相关sql都需要改动

  2、分区,所有的数据还在一个表中,但物理存储数据根据一定的规则存放在不同的文件中,文件也可以放到另外磁盘上

    优点:代码维护量小,基本不用改动,提高IO吞吐量
    缺点:表的并发程度没有增加

  3、拆分业务,这个本质还是分表。

    优点:长期支持更好
    缺点:代码逻辑重构,工作量很大

  当然,每种情况都有合适的应用场景,需要根据具体业务具体选择。由于分表和拆分业务和mysql本身关系不大属于业务层面,我们只说和数据库关系最紧密的方式:表分区。不过使用表分区有个前提就是你的数据库必须支持。那么,怎么知道我的数据库是否支持表分区呢 ? 请执行下面命令  

代码如下:

show plugins;  ---在mysql控制台中执行

据说5.4一下的版本是另外一个命令,不过我没有测试

代码如下:

show variables like '%part%';

  数据库的表分区一般有两种方式:纵向和横向。纵向就是把表中不同字段分到不同数据文件中。横向是把表中前一部分数据放到一个文件中,另一部分数据放到一个文件中。mysql只支持后后一种方式,横向拆分。

1、创建分区表

  如果要使用表的分区优势,不但要数据库版本支持分区,关键要建分区表,这个表和普通表不一样,并且必须建表的时候就要指定分区,否则无法把普通表改成分区表。那么,如果创建一个分区表呢? 其他很简单,请看下面建表语句

CREATE TABLE `T_part` (
  `f_id` INT DEFAULT NULL,
  `f_name` VARCHAR (20) DEFAULT NULL,
  PRIMARY KEY (`f_id`)
) ENGINE = myisam DEFAULT CHARSET = utf8
PARTITION BY RANGE (f_id)(    -----指定分区方式
  PARTITION p0 VALUES less THAN (10),-- 分了两个区
  PARTITION p1 VALUES less THAN (20)
)

上面语句建了一个“T_part”表,有两个字段f_id和f_name,并且根据RANGE方式把表分成两个区p0、p1,当f_id小于10放入p0分区,当f_id大于0小于20放入分区p1. 那么当f_id大于20的数据放入哪个分区呢? 你猜对了,insert语句会报错。

  看到了吧,创建分区表就这么简单!当然,你随时可以添加删除分区,不过要注意,删除分区的时候会把当前分区下所有数据都删除。

代码如下:

alter table T_part add partition(partition p2 values less than (MAXVALUE));  ---新增分区
alter table T_part DROP partition p2; ----删除分区

2、表分区的几种方式
   mysql支持5种分区方式:RANGE分区、LIST分区、HASH分区、LINEAR HASH分区和KEY分区。每种分区都有自己的使用场景。

  1)RANGE分区:

    RANGE分区的表是通过如下一种方式进行分区的,每个分区包含那些分区表达式的值位于一个给定的连续区间内的行。这些区间要连续且不能相互重叠,使用VALUES LESS THAN操作符来进行定义。

    上面的例子就是RANGE分区.

  2)LIST分区:

    MySQL中的LIST分区在很多方面类似于RANGE分区。和按照RANGE分区一样,每个分区必须明确定义。它们的主要区别在于,LIST分区中每个分区的定义和选择是基于某列的值从属于一个值列表集中的一个值,而RANGE分区是从属于一个连续区间值的集合。LIST分区通过使用“PARTITION BY LIST(expr)”来实现,其中“expr” 是某列值或一个基于某个列值、并返回一个整数值的表达式,然后通过“VALUES IN (value_list)”的方式来定义每个分区,其中“value_list”是一个通过逗号分隔的整数列表。

CREATE TABLE `T_list` (
  `f_id` INT DEFAULT NULL,
  `f_name` VARCHAR (20) DEFAULT NULL,
  PRIMARY KEY (`f_id`)
) ENGINE = myisam DEFAULT CHARSET = utf8
PARTITION by list(f_id)
(
 PARTITION p0 VALUES in(1,2,3), ----区间值不能重复
 PARTITION p1 VALUES in(4,5,6)
);

3)HASH分区:

    HASH分区主要用来确保数据在预先确定数目的分区中平均分布。在RANGE和LIST分区中,必须明确指定一个给定的列值或列值集合应该保存在哪个分区中;而在HASH分区中,MySQL 自动完成这些工作,你所要做的只是基于将要被哈希的列值指定一个列值或表达式,以及指定被分区的表将要被分割成的分区数量。要使用HASH分区来分割一个表,要在CREATE TABLE 语句上添加一个“PARTITION BY HASH (expr)”子句,其中“expr”是一个返回一个整数的表达式。它可以仅仅是字段类型为MySQL 整型的一列的名字。此外,你很可能需要在后面再添加一个“PARTITIONS num”子句,其中num 是一个非负的整数,它表示表将要被分割成分区的数量。

CREATE TABLE `T_hash` (
  `f_id` INT DEFAULT NULL,
  `f_name` VARCHAR (20) DEFAULT NULL,
  PRIMARY KEY (`f_id`)
) ENGINE = myisam DEFAULT CHARSET = utf8
PARTITION BY HASH(f_id) ---可以指定多列
PARTITIONS 4;---分区个数

“expr”还可以是MySQL 中有效的任何函数或其他表达式,只要它们返回一个既非常数、也非随机数的整数。(换句话说,它既是变化的但又是确定的)。但是应当记住,每当插入或更新(或者可能删除)一行,这个表达式都要计算一次;这意味着非常复杂的表达式可能会引起性能问题,尤其是在执行同时影响大量行的运算(例如批量插入)的时候。最有效率的哈希函数是只对单个表列进行计算,并且它的值随列值进行一致地增大或减小,因为这考虑了在分区范围上的“修剪”。也就是说,表达式值和它所基于的列的值变化越接近,MySQL就可以越有效地使用该表达式来进行HASH分区。

  4)LINEAR HASH分区:

    MySQL还支持线性哈希功能,它与常规哈希的区别在于,线性哈希功能使用的一个线性的2的幂(powers-oftwo)运算法则,而常规 哈希使用的是求哈希函数值的模数。线性哈希分区和常规哈希分区在语法上的唯一区别在于,在“PARTITION BY” 子句中添加“LINEAR”关键字.

  5)KEY分区:

    按照KEY进行分区类似于按照HASH分区,除了HASH分区使用的用户定义的表达式,而KEY分区的 哈希函数是由MySQL 服务器提供。MySQL 簇(Cluster)使用函数MD5()来实现KEY分区;对于使用其他存储引擎的表,服务器使用其自己内部的 哈希函数,这些函数是基于与PASSWORD()一样的运算法则。

    KEY分区的语法和HASH语法类似,只是把关键字改成KEY。  

CREATE TABLE `T_key` (
  `f_id` INT DEFAULT NULL,
  `f_name` VARCHAR (20) DEFAULT NULL,
  PRIMARY KEY (`f_id`)
) ENGINE = myisam DEFAULT CHARSET = utf8
PARTITION BY LINEAR key(f_id)
PARTITIONS 3;

6)子分区:

    子分区的意思就是在分区的基础上再次分区。且每个分区必须有相同个数的子分区。

CREATE TABLE `T_part` (
  `f_id` INT DEFAULT NULL,
  `f_name` VARCHAR (20) DEFAULT NULL,
  PRIMARY KEY (`f_id`)
)
PARTITION BY RANGE (f_id)
SUBPARTITION BY HASH(F_ID)
SUBPARTITIONS 2
(
  PARTITION p0   VALUES     less THAN (10),
  PARTITION p1  VALUES    less THAN (20)
)

上面语句的意思是,建立两个range分区,每个分区根据hash有分别有两个子分区,实际上整个表分成2×2=4个分区。当然,要详细定义每个分区属性也是可以的

CREATE TABLE `T_part` (
  `f_id` INT DEFAULT NULL,
  `f_name` VARCHAR (20) DEFAULT NULL,
  PRIMARY KEY (`f_id`)
)
PARTITION BY RANGE (f_id)
SUBPARTITION BY HASH(F_ID)
(
  PARTITION p0   VALUES less THAN (10)
  (
    SUBPARTITION s0
      DATA DIRECTORY = '/disk0/data'
      INDEX DIRECTORY = '/disk0/idx',
    SUBPARTITION s1
      DATA DIRECTORY = '/disk1/data'
      INDEX DIRECTORY = '/disk1/idx'
  ),
  PARTITION p1  VALUES less THAN (20)
  (
    SUBPARTITION s2
      DATA DIRECTORY = '/disk0/data'
      INDEX DIRECTORY = '/disk0/idx',
    SUBPARTITION s3
      DATA DIRECTORY = '/disk1/data'
      INDEX DIRECTORY = '/disk1/idx'
  )
)

这样可以对每个分区指定具体存储磁盘。前提磁盘是存在的。  

  MySQL 中的分区在禁止空值(NULL)上没有进行处理,无论它是一个列值还是一个用户定义表达式的值。一般而言,在这种情况下MySQL 把NULL视为0。如果你希望回避这种做法,你应该在设计表时不允许空值;最可能的方法是,通过声明列“NOT NULL”来实现这一点。

(0)

相关推荐

  • Mysql分区表的管理与维护

    改变一个表的分区方案只需使用alter table 加 partition_options 子句就可以了.和创建分区表时的create table语句很像. 创建表 CREATE TABLE trb3 (id INT, name VARCHAR(50), purchased DATE) PARTITION BY RANGE( YEAR(purchased) ) ( PARTITION p0 VALUES LESS THAN (1990), PARTITION p1 VALUES LESS THA

  • Rails中使用MySQL分区表一个提升性能的方法

    MySQL 的分区表是一种简单有效的处理极大数据表的特性,通过它可以使应用程序几乎很少改动就能达成对极大数据表的高效处理,但由于 Rails ActiveRecord 设计上一些惯例,可能导致一些数据处理不能利用分区表特性,反而变得很慢,在使用分区表过程中一定要多加注意. 下面以一个例子来说明.在 light 系统中,有一张数据表是 diet_items, 主要字段是 id, schedule_id, meal_order food_id, weight, calory 等等,它的每一条记录表示

  • mysql使用教程之分区表的使用方法(删除分区表)

    MySQL使用分区表的好处: 1,可以把一些归类的数据放在一个分区中,可以减少服务器检查数据的数量加快查询.2,方便维护,通过删除分区来删除老的数据.3,分区数据可以被分布到不同的物理位置,可以做分布式有效利用多个硬盘驱动器. MySQL可以建立四种分区类型的分区: RANGE 分区:基于属于一个给定连续区间的列值,把多行分配给分区. LIST 分区:类似于按RANGE分区,区别在于LIST分区是基于列值匹配一个离散值集合中的某个值来进行选择.  www.jb51.net HASH分区:基于用户

  • MySQL分区表的局限和限制详解

    禁止构建 分区表达式不支持以下几种构建: 存储过程,存储函数,UDFS或者插件 声明变量或者用户变量 可以参考分区不支持的SQL函数 算术和逻辑运算符 分区表达式支持+,-,*算术运算,但是不支持DIV和/运算(还存在,可以查看Bug #30188, Bug #33182).但是,结果必须是整形或者NULL(线性分区键除外,想了解更多信息,可以查看分区类型). 分区表达式不支持位运算:|,&,^,<<,>>,~ . HANDLER语句 在MySQL 5.7.1之前的分区表不

  • MySQL优化之分区表

    当数据库数据量涨到一定数量时,性能就成为我们不能不关注的问题,如何优化呢? 常用的方式不外乎那么几种: 1.分表,即把一个很大的表达数据分到几个表中,这样每个表数据都不多. 优点:提高并发量,减小锁的粒度 缺点:代码维护成本高,相关sql都需要改动 2.分区,所有的数据还在一个表中,但物理存储数据根据一定的规则存放在不同的文件中,文件也可以放到另外磁盘上 优点:代码维护量小,基本不用改动,提高IO吞吐量 缺点:表的并发程度没有增加 3.拆分业务,这个本质还是分表. 优点:长期支持更好 缺点:代码

  • MySQL优化总结-查询总条数

    1.COUNT(*)和COUNT(COL) COUNT(*)通常是对主键进行索引扫描,而COUNT(COL)就不一定了,另外前者是统计表中的所有符合的纪录总数,而后者是计算表中所有符合的COL的纪录数.还有有区别的. 优化总结,对于MyISAM表来说: 1.任何情况下SELECT COUNT(*) FROM tablename是最优选择: 2.尽量减少SELECT COUNT(*) FROMtablename WHERE COL = 'value' 这种查询: 3.杜绝SELECT COUNT(

  • mysql优化利器之explain使用介绍

    一.语法 {EXPLAIN | DESCRIBE | DESC} tbl_name [col_name | wild] {EXPLAIN | DESCRIBE | DESC} [explain_type] SELECT select_options explain_type: {EXTENDED | PARTITIONS} 二.数据库准备 表一: DROP TABLE IF EXISTS `products`; SET @saved_cs_client = @@character_set_cli

  • mysql 优化日记

    同时在线访问量继续增大 对于1G内存的服务器明显感觉到吃力严重时甚至每天都会死机 或者时不时的服务器卡一下 这个问题曾经困扰了我半个多月MySQL使用是很具伸缩性的算法,因此你通常能用很少的内存运行或给MySQL更多的被存以得到更好的性能. 安装好mysql后,配制文件应该在/usr/local/mysql/share/mysql目录中,配制文件有几个,有my-huge.cnf my-medium.cnf my-large.cnf my-small.cnf,不同的流量的网站和不同配制的服务器环境

  • PHP数据库编程之MySQL优化策略概述

    本文简单讲述了PHP数据库编程之MySQL优化策略.分享给大家供大家参考,具体如下: 前些天看到一篇文章说到PHP的瓶颈很多情况下不在PHP自身,而在于数据库.我们都知道,PHP开发中,数据的增删改查是核心.为了提升PHP的运行效率,程序员不光需要写出逻辑清晰,效率很高的代码,还要能对query语句进行优化.虽然我们对数据库的读取写入速度上却是无能为力,但在一些数据库类扩展像memcache.mongodb.redis这样的数据存储服务器的帮助下,PHP也能达到更快的存取速度,所以了解学习这些扩

  • MySQL优化之使用连接(join)代替子查询

    使用连接(JOIN)来代替子查询(Sub-Queries) MySQL从4.1开始支持SQL的子查询.这个技术可以使用SELECT语句来创建一个单列的查询结果,然后把这个结果作为过滤条件用在另一个查询中.例如,我们要将客户基本信息表中没有任何订单的客户删除掉,就可以利用子查询先从销售信息表中将所有发出订单的客户ID取出来,然后将结果传递给主查询,如下所示: DELETE FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FR

  • 通过MySQL优化Discuz!的热帖翻页的技巧

    写在前面:discuz!作为首屈一指的社区系统,为广大站长提供了一站式网站解决方案,而且是开源的(虽然部分代码是加密的),它为这个垂直领域的行业发展作出了巨大贡献.尽管如此,discuz!系统源码中,还是或多或少有些坑.其中最著名的就是默认采用MyISAM引擎,以及基于MyISAM引擎的抢楼功能,session表采用memory引擎等,可以参考后面几篇历史文章.本次我们要说说discuz!在应对热们帖子翻页逻辑功能中的另一个问题. 在我们的环境中,使用的是 MySQL-5.6.6 版本. 在查看

  • 企业生产MySQL优化介绍

    与其他的大型数据库例如 Oracle.DB2.SQL Server等相比,MySQL 自有它的不足之处,但是这丝毫也没有减少它受欢迎的程度.对于一般的个人使用者和中小型企业来说,MySQL提供的功能已经绰绰有余,而且由于 MySQL是开放源码软件,因此可以大大降低总体拥有成本. 企业生产MySQL是如何优化的呢? 参考答案: a:硬件的优化: 1.    采用64位cpu,cpu至少4颗,L2缓存越大越好 2.    内存要大,32-64G运行1-2个实例,96-128G运行3-4个实例 3. 

  • 记一次因线上mysql优化器误判引起慢查询事件

    前言: 收到疯狂的慢查询及请求超时报警,通过metrics分析出来自mysql请求的异常,cli -> show proceslist 看到很多慢查询. 先前该sql是没有的,后面因为数据量的增长才出现了这问题. 虽然feeds表大到一个亿,但因为feeds流信息有近期热的特征,所以不是因为 innodb_buffer_pool_size 低效引起的io频繁. 后来经过进一步explain执行计划分析得出了原因,mysql查询优化器选择了他认为高效的索引. mysql查询优化器大多数情况是靠谱的

  • MySQL优化之连接优化

    上文MySQL优化之缓存优化 这篇文章中提到了一个很重要的概念,就是show variables是用来表示系统编译或者配置在my.cnf中的变量值.而show status则称之为状态值,显示的是当前服务实例运行所具有的状态信息,是一个动态改变的值.因此常用来观测当前MySQl的运行是否正常,如果不正常那么依靠调整静态参数来提高MySQL的性能.所以明白这两个概念的不同,是后面调优的基础. MySQL 连接优化 记得有一次在公司内部连接MySQL的时候,总是连接不上.找到DBA后,经过排查原因,

随机推荐