MySQL 高级特性（二）：数据表分区策略及优缺点分析

当面对巨大的数据表的时候，至少有一件事情是确定的，表太大了以至于每次查询的时候我们没法做全表扫描。而这个时候也没法使用索引，或者说索引意义不大，更不用说索引的维护代价和空间占用非常高。如果是依赖索引，会导致大量的碎片和低聚集度的数据，这会导致查询的时候有上千次的随机 I/O 访问而导致宕机。这种情况下一般只会使用1-2个索引，而不会更多。这种情况下，有两个可行的选项：查询必须从数据表的指定的部分顺序查找或者是期望的部分数据及其索引与服务器的内存匹配。

需要再次重申：在存储空间过大时，除非索引覆盖了整个查询，否则二叉树索引就无法发挥作用。服务端需要查找数据表的一整行数据，并且会在一个大空间跨度里执行随机 I/O *** 作，这会导致查询响应时间无法接受。而维护索引（磁盘空间，I/O *** 作）的代价同样很高。

而这是分区能够解决的问题。这其中的关键就是分区是索引的一个初级形式，它的负荷低并且能够让我们从临近的数据中获取结果。这种情形下，我们可以依次扫描相邻的数据或者是将临近的数据加载到内存进行检索。分区之所以负荷低是因为它并没有指针指向对应的数据行，也不需要被更新。分区并不精确地将数据按行划分，也没有涉及到所谓的数据结构。实际上，分区相当于对数据进行了分类。

对于大数据表，有两种策略进行分区：

两种分区策略是基于两个关键假设：在查询的时候可以通过过滤分区缩小查找范围，且分区自身的代价不高。然而，这两个假设未必总是有效，下面是可能遇到的问题：

如上所述，分区并不是完美解决方案，目前版本的 MySQL还有一些其他的约束：

当然，随着 MySQL 版本的更新迭代，对分区的支持也越来越好，并且很多分区的问题都得到了修复。

当数据库表中数据量能够被预测到将会非常大，或者已经拥有庞大的数据时，我们应该选择分表或者分区（即使用多个数据库）来解决数据访问时的性能问题。如果单机的cpu能够承受站点的并发数，应该选择分表的方式，因为分表相对简单，容易实现scale，而且涉及到多表连接时，分区是不能直接使用join的。但如果站点并发数太大，需要多个cpu来访问多个数据库是无疑的，这时需要选择分区的方式。

详细参考：http://blog.csdn.net/changdazhong/archive/2011/03/27/6281772.aspx

---