成这些工作，你所要做的只是基于将要被哈希的列值指定一个列值或表达式，以及指定被分区的表将要被分割成的分区数量。

例如，下面的语句创建了一个使用基于“store_id”列进行哈希处理的表，该表被分成了4个分区：

CREATE TABLE employees (

    id INT NOT NULL,

    fname VARCHAR(30),

    lname VARCHAR(30),

    hired DATE NOT NULL DEFAULT '1970-01-01',

    separated DATE NOT NULL DEFAULT '9999-12-31',

    job_code INT,

    store_id INT

)

PARTITION BY HASH(store_id)

PARTITIONS 4；

如果没有包括一个PARTITIONS子句，那么分区的数量将默认为1

1.4 KEY分区

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

“CREATETABLE ... PARTITION BY KEY”的语法规则类似于创建一个通过HASH分区的表的规则。它们唯一的区别在于使用的关键字是KEY而不是HASH，并且KEY分区只采用一个或多个列名的一个列表。

通过线性KEY分割一个表也是可能的。下面是一个简单的例子：

CREATE TABLE tk (

    col1 INT NOT NULL,

    col2 CHAR(5),

    col3 DATE

) 

PARTITION BY LINEAR KEY (col1)

PARTITIONS 3;

在KEY分区中使用关键字LINEAR和在HASH分区中使用具有同样的作用，分区的编号是通过2的幂（powers-of-two）算法得到，而不是通过模数算法

1.5 更多的知识

上面列出的仅仅是常用的分区策略的用法，当创建了分区后往往还要对分区进行维护，具体请参见：

http://dev.mysql.com/doc/refman/5.1/zh/partitioning.html#partitioning-hash

无论使用何种类型的分区，分区总是在创建时就自动的顺序编号，且从0开始记录，记住这一点非常重要。当有一新行插入到一个分区表中时，就是使用这些分区编号来识别正确的分区。例如，如果你的表使用4个分区，那么这些分区就编号为0, 1, 2, 和3。对于RANGE和LIST分区类型，确认每个分区编号都定义了一个分区，很有必要。对HASH分区，使用的用户函数必须返回一个大于0的整数值。对于KEY分区，这个问题通过MySQL服务器内部使用的哈希函数自动进行处理。

2 使用分区表的限制

· 一个数据表最多只能有1024个分区

· 在MYSQL5.1 版本中分区表达式的结果必须是整数，在MYSQL5.5分区表达式可以使用列

· 如果分区字段中有主键或者是唯一索引列，则所有的主键或者是唯一索引列必须全部包含进来

· 分区表无法使用外键

· 对于同一个表的各个分区表必须使用相同的存储引擎

· 分区函数有限制，只可以是MySQL 中有效的任何函数或其他表达式，且它们返回一个既非常数、也非随机数的整数

· 某些存储引擎不支持分区

3 使用分区表的“陷阱”

在数据量非常大的时候使用分区表可以使性能有较好的改善，但是前提是必须能有效的规避下面列出的一些陷阱

· NULL值

MySQL 中的分区在禁止空值（NULL）上没有进行处理，无论它是一个列值还是一个用户定义表达式的值。一般而言，对于NULL,或者是当表达式接收非法值时（e.g. YEAR(‘asdf-12-12’)）返回的结果都是NULL,在这种情况下MySQL 把NULL视为0,如果大量的记录存在这种情况，最终会导致大量的记录都集中在一个分区中，也也就违背了分区的初衷。

如果你希望回避这种做法，你应该在设计表时不允许空值；最可能的方法是，通过声明列“NOT NULL”来实现这一点。

· 分区列和索引列不匹配

如果定义的索引列和分区列不匹配，则会导致查询无法进行分区过滤。例如在列a上定义分区，在列b上定义索引，因为每个分区都有独立的索引，所以扫描索引时需要扫描每个分区。

应该避免建立和分区列不匹配的索引，除非查询中包含了可以过滤分区的条件。

· 选择分区的成本很高

对于Range 和list类型的分区，每次进行操作时都需要遍历所有的分区条件，以判断相关的记录是属于哪个分区，如果分区的数量很多，会在选择分区上浪费较多的资源

为了避免这种情况可以限制分区的数目（<100）,或是选择hash分区

· 锁住底层表的成本很高

在查询访问分区表的时候，MYSQL会打开并锁住所有的底层表，该操作时再分区过滤之前发生而且和分区类型无关，会影响所有的分区查询。

可以通过批量更新的方式来降低该操作的次数，同时也需要限制分区的数目

· 维护成本高

增加/删除分区很快捷，但是重组或者是alter分区的过程类似于alter table,会进行大量的数据复制操作，效率很低。

4 优化查询语句

对于分区表的访问，最重要的一点是要在where条件中包含分区列，即使看起来是多余的，只有这样才能过滤不需要的分区，否则会访问所以的分区表。

看一个简单的例子。

Employees表使用store_id作为范围分区的条件，如果不使用store_id作为where条件，会查询所有的分区

Store_id作为where条件时，只查询对应的分区

关于where条件中的表达式有几点需要注意

· 单纯的使用分区列

Where条件中分区列必须是未经函数处理的，如果where条件写成where YEAR(store_id), 则分区过滤会失效，且查询时会检查所有的分区。这一点和索引类似

· 关联查询

如果分区表是关联操作的第二张表，且关联条件是分区建，则MYSQL只会在对应的分区里进行匹配

高性能MySql进化论(十二):Mysql中分区表的使用总结(二)

1.4 KEY分区

1.5 更多的知识

2 使用分区表的限制

3 使用分区表的“陷阱”

4 优化查询语句