对Vertical Partitioning的一些看法

虽然MySQL5.1自动实现了水平分区，但在设计数据库的时候不要轻视垂直分区。虽然要手工去实现垂直分区，但在特定场合下你会收益不少的。例如在前面建立的表中，VARC­HAR字段是你平常很少引用的，那么对它进行垂直分区会不会提升速度呢？咱们看看测试结果：

mysql> desc part_tab;

+-------+-------------+------+-----+---------+-------+

| Field | Type        | Null | Key | Default | Extra |

+-------+-------------+------+-----+---------+-------+

| c1    | int(11)     | YES  |     | NULL    |       |

| c2    | varchar(30) | YES  |     | NULL    |       |

| c3    | date        | YES  |     | NULL    |       |

+-------+-------------+------+-----+---------+-------+

3 rows in set (0.03 sec)

mysql> alter table part_tab drop column c2;

Query OK, 8000000 rows affected (42.20 sec)

Records: 8000000  Duplicates: 0  Warnings: 0

mysql> desc part_tab;

+-------+---------+------+-----+---------+-------+

| Field | Type    | Null | Key | Default | Extra |

+-------+---------+------+-----+---------+-------+

| c1    | int(11) | YES  |     | NULL    |       |

| c3    | date    | YES  |     | NULL    |       |

+-------+---------+------+-----+---------+-------+

2 rows in set (0.00 sec)

mysql> select count(*) from part_tab where

    -> c3 > date '1995-01-01' and c3 < date '1995-12-31';

+----------+

| count(*) |

+----------+

|   795181 |

+----------+

1 row in set (0.34 sec)

在设计上去掉了VARCHAR字段后，不止是你，俺也发现查询响应速度上获得了另一个90％的时间节省。所以大家在设计表的时候，一定要考虑，表中的字段是否真­正关联，又是否在你的查询中有用？

补充说明

这么简单的文章肯定不能说全MySQL 5.1 分区机制的所有好处和要点（虽然对自己写文章水平很有信心），下面就说几个感兴趣的：

支持所有存储引擎(MyISAM, Archive, InnoDB, 等等) 对分区的表支持索引，包括本地索引local  indexes，对其进行的是一对一的视图镜像，假设一个表有十个分区，那么其本地索引也包含十个分区。

关于分区的元数据Metadata的表可以在INFORMATION_SCHEMA数据库中找到，表名为PARTITIONS。

All SHOW 命令支持返回分区表以及元数据的索引。 对其操作的命令和实现的维护功能有（比对全表的操作还多）：

ADD PARTITION
DROP PARTITION
COALESCE PARTITION
REORGANIZE PARTITION
ANALYZE PARTITION
CHECK PARTITION
OPTIMIZE PARTITION
REBUILD PARTITION
REPAIR PARTITION
站在性能主导的观点上来说，MySQL
5.1的分区功能能给数据性能带来巨大的提升的同时减轻DBA的管理负担，如果分区合理的话。如果需要更多的资料可以去http://dev.mysql.com/doc/refman/5.1/en/partitioning.html或
http://forums.mysql.com/list.php?106获得相关资料。