mysql自身只支持表的横向分区。

常听到开发人员说“”对表做个分区“，然后数据的查询就会快了。这是真的吗？实际上可能跟根本感觉不到查询速度的提升，甚至会发现查询速度急剧下降。因此，在合理使用分区之前，必须了解分区的使用环境。

数据的应用分为两类：一类是OLTP（在线事务处理），如Blog、电子商务、网络游戏等；另一类是OLAP（在线分析处理），如数据仓库、数据集市。在一个实际的应用环境中，可能既有OLTP的引用，也有OLAP的应用。如网络游戏中，玩家操作的游戏数据库应用就是OLTP的，但是游戏厂商可能需要对游戏产生的日志进行分析，通过分析得到的结果来更好地服务游戏，预测玩家的行为等，而这确实OLAP的应用。

对于OLAP的应用，分区的确是可以很好地提高查询性能，因为OLAP应用太多数查询需要频繁扫描一张很大的表。假设有一张1亿行的表，其中有一个时间戳属性列。用户的查询需要从这张表中获取一年的数据，如果按照时间戳进行分区，则需要扫描响应的表即可。这可以称为分区修剪。

然而对于OLTP的应用，分表应该非常小心，在这种应用下，通常不可能会获取一张大表中10%的数据，大部分都是通过索引返回几条记录即可。而根据B+树索引的原理可知，对于一张一张大表，一般的B+树需要2~3次的磁盘IO。因此B+树可以很好地完成操作，不需要分区的帮助，并且设计不好的分区会带来验证的性能问题，甚至还会带来额外的无法避免的问题。

发现很多开发团队人为含有1000W行的表是一张非常巨大的表，所以他们往往会选择采用分区，如对主键做10个hash的分区，这样每个分区就只有100W的数据了，因此查询应该变得更快乐，如 SELECT * FROM WHERE PK=@pk 但是有没有考虑过这样一种情况： 100W和1000W行的数据本身构成的B+树的层次都是一样的，可能都是2层。那么上走主键分区的索引并不会带来性能的提高。好的，如果1000w的B+树的高度是3,100W的B+树的高度是2，那么上述按主键分区的索引可以避免1次IO,从而提高查询效率。没问题，但是这张表只有主键索引，没有任何其他的列需要查询的。如果还有类似的sql语句：SELECT * FROM TABLE WHERE KEY=@key，这时对于KEY的查询需要扫描所有的10个分区，即使每个分区的查询开销为2次IO,ze yigong xuyao 20ci IO。而杜宇原来单表的设计，对于KEY的查询只需要2~3次IO.