引用地址:http://blog.csdn.net/tjcyjd/article/details/11194489mysql
自5.1开始对分区(Partition)有支持
= 水平分区(根据列属性按行分)=
举个简单例子:一个包含十年发票记录的表能够被分区为十个不一样的分区,每一个分区包含的是其中一年的记录。
=== 水平分区的几种模式:===
* Range(范围) – 这种模式容许DBA将数据划分不一样范围。例如DBA能够将一个表经过年份划分红三个分区,80年代(1980's)的数据,90年代(1990's)的数据以及任何在2000年(包括2000年)后的数据。
* Hash(哈希) – 这中模式容许DBA经过对表的一个或多个列的Hash Key进行计算,最后经过这个Hash码不一样数值对应的数据区域进行分区,。例如DBA能够创建一个对表主键进行分区的表。
* Key(键值) – 上面Hash模式的一种延伸,这里的Hash Key是MySQL系统产生的。
* List(预约义列表) – 这种模式容许系统经过DBA定义的列表的值所对应的行数据进行分割。例如:DBA创建了一个横跨三个分区的表,分别根据2004年2005年和2006年值所对应的数据。
* Composite(复合模式) - 很神秘吧,哈哈,实际上是以上模式的组合使用而已,就不解释了。举例:在初始化已经进行了Range范围分区的表上,咱们能够对其中一个分区再进行hash哈希分区。
= 垂直分区(按列分)=
举个简单例子:一个包含了大text和BLOB列的表,这些text和BLOB列又不常常被访问,这时候就要把这些不常常使用的text和BLOB了划分到另外一个分区,在保证它们数据相关性的同时还能提升访问速度。
[分区表和未分区表试验过程]
*建立分区表,按日期的年份拆分
sql
注意最后一行,考虑到可能的最大值
*建立未分区表
数据库
*经过存储过程灌入800万条测试数据
mysql> set sql_mode=''; /* 若是建立存储过程失败,则先需设置此变量, bug? */
性能
mysql> delimiter // /* 设定语句终结符为 //,因存储过程语句用;结束 */测试
Query OK, 1 row affected (8 min 17.75 sec)
大数据
Query OK, 8000000 rows affected (51.59 sec)
Records: 8000000 Duplicates: 0 Warnings: 0
ui
* 测试SQL性能this
+----------+
| count(*) |
+----------+
| 795181 |
+----------+
spa
1 row in set (0.55 sec).net
+----------+
| count(*) |
+----------+
| 795181 |
+----------+
1 row in set (4.69 sec)
结果代表分区表比未分区表的执行时间少90%。
* 经过explain语句来分析执行状况
/* 结尾的\G使得mysql的输出改成列模式 */
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: no_part_tab
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 8000000
Extra: Using where
1 row in set (0.00 sec)
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: part_tab
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 798458
Extra: Using where
1 row in set (0.00 sec)
explain语句显示了SQL查询要处理的记录数目
* 试验建立索引后状况
Query OK, 8000000 rows affected (1 min 18.08 sec)
Records: 8000000 Duplicates: 0 Warnings: 0
Query OK, 8000000 rows affected (1 min 19.19 sec)
Records: 8000000 Duplicates: 0 Warnings: 0
建立索引后的数据库文件大小列表:
2008-05-24 09:23 8,608 no_part_tab.frm
2008-05-24 09:24 255,999,996 no_part_tab.MYD
2008-05-24 09:24 81,611,776 no_part_tab.MYI
2008-05-24 09:25 0 part_tab#P#p0.MYD
2008-05-24 09:26 1,024 part_tab#P#p0.MYI
2008-05-24 09:26 25,550,656 part_tab#P#p1.MYD
2008-05-24 09:26 8,148,992 part_tab#P#p1.MYI
2008-05-24 09:26 25,620,192 part_tab#P#p10.MYD
2008-05-24 09:26 8,170,496 part_tab#P#p10.MYI
2008-05-24 09:25 0 part_tab#P#p11.MYD
2008-05-24 09:26 1,024 part_tab#P#p11.MYI
2008-05-24 09:26 25,656,512 part_tab#P#p2.MYD
2008-05-24 09:26 8,181,760 part_tab#P#p2.MYI
2008-05-24 09:26 25,586,880 part_tab#P#p3.MYD
2008-05-24 09:26 8,160,256 part_tab#P#p3.MYI
2008-05-24 09:26 25,585,696 part_tab#P#p4.MYD
2008-05-24 09:26 8,159,232 part_tab#P#p4.MYI
2008-05-24 09:26 25,585,216 part_tab#P#p5.MYD
2008-05-24 09:26 8,159,232 part_tab#P#p5.MYI
2008-05-24 09:26 25,655,740 part_tab#P#p6.MYD
2008-05-24 09:26 8,181,760 part_tab#P#p6.MYI
2008-05-24 09:26 25,586,528 part_tab#P#p7.MYD
2008-05-24 09:26 8,160,256 part_tab#P#p7.MYI
2008-05-24 09:26 25,586,752 part_tab#P#p8.MYD
2008-05-24 09:26 8,160,256 part_tab#P#p8.MYI
2008-05-24 09:26 25,585,824 part_tab#P#p9.MYD
2008-05-24 09:26 8,159,232 part_tab#P#p9.MYI
2008-05-24 09:25 8,608 part_tab.frm
2008-05-24 09:25 68 part_tab.par
* 再次测试SQL性能
+----------+
| count(*) |
+----------+
| 795181 |
+----------+
1 row in set (2.42 sec) /* 为原来4.69 sec 的51%*/
重启mysql ( net stop mysql, net start mysql)后,查询时间降为0.89 sec,几乎与分区表相同。
+----------+
| count(*) |
+----------+
| 795181 |
+----------+
1 row in set (0.86 sec)
* 更进一步的试验
** 增长日期范围
+----------+
| count(*) |
+----------+
| 2396524 |
+----------+
1 row in set (5.42 sec)
+----------+
| count(*) |
+----------+
| 2396524 |
+----------+
1 row in set (2.63 sec)
** 增长未索引字段查询
+----------+
| count(*) |
+----------+
| 0 |
+----------+
1 row in set (0.75 sec)
+----------+
| count(*) |
+----------+
| 0 |
+----------+
1 row in set (11.52 sec)
= 初步结论 =
* 分区和未分区占用文件空间大体相同 (数据和索引文件)
* 若是查询语句中有未创建索引字段,分区时间远远优于未分区时间
* 若是查询语句中字段创建了索引,分区和未分区的差异缩小,分区略优于未分区。
= 最终结论 =
* 对于大数据量,建议使用分区功能。
* 去除没必要要的字段
* 根据手册, 增长myisam_max_sort_file_size 会增长分区性能
[分区命令详解]
= 分区例子 =
* RANGE 类型
在这里,将用户表分红4个分区,以每300万条记录为界限,每一个分区都有本身独立的数据、索引文件的存放目录,与此同时,这些目录所在的物理磁盘分区可能也都是彻底独立的,能够提升磁盘IO吞吐量。
* LIST 类型
分红4个区,数据文件和索引文件单独存放。
* HASH 类型
分红4个区,数据文件和索引文件单独存放。
例子:
* KEY 类型
分红4个区,数据文件和索引文件单独存放。
* 子分区
子分区是针对 RANGE/LIST 类型的分区表中每一个分区的再次分割。再次分割能够是 HASH/KEY 等类型。例如:
对 RANGE 分区再次进行子分区划分,子分区采用 HASH 类型。
或者
对 RANGE 分区再次进行子分区划分,子分区采用 KEY 类型。
= 分区管理 =
* 删除分区
删除分区 p0。
* 重建分区
o RANGE 分区重建
将原来的 p0,p1 分区合并起来,放到新的 p0 分区中。
o LIST 分区重建
将原来的 p0,p1 分区合并起来,放到新的 p0 分区中。
o HASH/KEY 分区重建
用 REORGANIZE 方式重建分区的数量变成2,在这里数量只能减小不能增长。想要增长能够用 ADD PARTITION 方法。
* 新增分区
o 新增 RANGE 分区
新增一个RANGE分区。
o 新增 HASH/KEY 分区
将分区总数扩展到8个。
[ 给已有的表加上分区 ]
默认分区限制分区字段必须是主键(PRIMARY KEY)的一部分,为了去除此
限制:
[方法1] 使用ID
ERROR 1503 (HY000): A PRIMARY KEY must include all columns in the table's partitioning function
However, this statement using the id column for the partitioning column is valid, as shown here:
Query OK, 0 rows affected (0.11 sec)
Records: 0 Duplicates: 0 Warnings: 0
[方法2] 将原有PK去掉生成新PK
Query OK, 5374850 rows affected (7 min 4.05 sec)
Records: 5374850 Duplicates: 0 Warnings: 0
Query OK, 5374850 rows affected (6 min 14.86 sec)
Records: 5374850 Duplicates: 0 Warnings: 0