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

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

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

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

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

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

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

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

Show Profile 是mysql提供可以用来分析 当前会话 中语句执行的资源消耗情况，可以用于Sql调优的测量。

请读者继续看前面的图 SQL执行具体细节 ，左边 Status 列展示了一条SQL执行的从开始到清理的整个生命周期中执行的 *** 作。如果在其生命周期阶段出现如下的情况的就要重视了：

开启 Profiling 后，mysql会留下15条最近执行的sql的 现场 , 便于我们发现问题。

Show profiles 用来查最近的15条。

Show profile 用来展示每一个SQL执行阶段的耗时清单，便于我们发现耗时最多的地方，然后以此为依据查找问题所在，最后优化SQL或者优化mysql参数。比如耗时清单创建了临时表，就要考虑表是否创建索引，如果创建了那么是否没有用到或者失效了。

总的来说 Profiling 是一个很不错的mysql性能分析工具。

如何分析mysql

A、设置索引项，应该是出现在where后面的列，或者连接字句中出现的列；

B、使用唯一索引，索引的基数越大，索引查询的效果越好，举例：查询条件中含有索引字段和非索引字段的时候，会优先走索引筛选出数据，然后在数据中回表过滤没有走索引的字段，但是Mysql任务，如果索引筛选出的数据量大于20%，会认为此时走索引效果不如全表扫描，继而放弃索引，走全表扫描来查询；

C、使用短索引，例如一个属性200多位，其实索引只要创建前几位效果会好；

D、最左原则，组合索引中，灵活运用最左前缀；

E、不要过度使用索引，索引会占用空间，影响写入的速度；

---