mysql高级特性之数据分区

mysql高级特性
  1 以存储引擎的角度分析，分区表和物理表没有区别。是按照一定的规则将数据分别存储的逻辑设计。器底层是由多个物理字表组成。
  
  2 分区的原理
     分区表由多个相关的底层表实现，这些底层表也是由句柄对象表示，所以我们可以直接访问各个分区。存储引擎管理分区的各个底层
	 表和管理普通表一样(所有底层表都必须使用相同的存储引擎)，分区表的索引只是在各个底层表上各自加上一个完全相同的索引。
	 从存储引擎角度来看，底层表和一个普通表没有任何的不同，存储引擎也无需知道这是一个普通表还是一个分区表。
	 在分区表中 索引已经失去作用，添加索引只会增加服务器的负担。如果发现某一些索引仍会起作用那也只是短暂的
	 回光返照。随着数据规模的增加，这些索引必然会成为负担。
	 
  3 分区表的类型
    1 根据范围进行分区
	2 根据实践间隔分区
	3 	mysql还支持键值、哈希、列表分区，这其中还支持子分区。
	4 还可以根据数学模函数来进行分区。
	

  4 如何使用分区表
    在分区表中，索引在空间和维护上的消耗巨大，尤其是当表非常大的时候，特别不希望使用索引，即使真的使用索引，你会
	发现数据并不是按照想要的方式聚集的，而且会有大量的碎片产生，最终会导致一个查询产生成千上万的随机IO，应用
	程序也随之僵死。有时候也可以通过一两个索引解决一些问题，不过多数情况下，索引不会有任何作用，这时候有两条路可选：
	让所有的查询都只在数据表上做顺序扫描，或者将数据表和索引全部都缓存在内存中。
	
	这里需要再陈述一遍，在数据量超大的时候，B-Tree索引就无法起作用了。除非是索引覆盖查询，否则数据库服务器
	需要根据索引扫描的结果回表查询所有符合条件的记录，如果数据量巨大，这将产生大量随机IO，随之，数据库的响应时间
	将大到不可接受。另外，索引维护(磁盘空间、IO操作)的代价也非常高。
	
	这正是分区所要做的事情。理解分区时还可以将其当做索引的最初形态，以待价非常小的方式定位到需要的数据在那一片区域。
	在这片区域中，你可以做顺序扫描，可以建索引，还可以将数据都缓存到内存等。因为分区无需额外的数据结构记录每个
	分区有哪些数据，分区不需要精确定位每条数据的位置，也就无需额外的数据结构，只需要一个简单的表达式就可以表达每个分区
	存放的是什么数据。
	
	为了保证大数据量的可扩展性，一般有下面两个策略：
	
	全量扫描数据，不需要任何索引。
	 可以使用简单的分区方式存放表，不需要任何索引，根据分区的规则大致定位需要的数据位置。只要能够使用where条件，将需要的数据限制在少数分区
	 中，则效率是非常高的。使用该策略假设不用将数据完全放入到内存中，同时还假设需要的数据全都在磁盘上，因为内存相对很小
	 数据很快会被挤出内存，所以缓存起不了任何作用。这个策略适用于以正常的方式访问大量数据的时候。
	 
	索引数据，并分离热点。
	  如果某部分数据有明显的热点，而且除了这部分数据，其他数据很少被访问到，那么可以将这部分热点数据单独放在一个分区中，
	  让这个分区的数据能够有机会都缓存在内存中。这样查询就可以只访问一个很小的分区表，能够使用索引，也能够有效的使用缓存。
	  
   5 分区的陷阱
     前面介绍的分区策略都基于两个非常重要的假设：查询都能够过滤掉很多额外的分区、分区本身不会带来很多额外的代价。
    事实是这两个假设在某些场景下会有问题。
	
	1)null值会使分区过滤无效
	  mysql分区时会创建第一个分区，用于存放分区列为null 或非法的记录。
	  例如 按照 partition by year(order_date) 来分区，那么order_date为null 或者是一个非法的值得时候，
	  记录都会被放入第一个分区。假设存在下面的查询 where order_date between 2012-09-08 and 2012-08-07
	  那么这个查询会检查2012这个分区，同时他还会检查第一个分区，检查第一个分区是因为year接受的参数
	  可能是null或者非法数值，如果是Null或者非法的话就会被放入第一个分区。
	  
	  同时，如果第一个分区非常大，特别是使用 全量扫描数据，不使用索引的策略时，代价会非常大。
	  
	  为了避免这种情况，我们可以创建一个无用的第一个分区，例如上面的例子可以使用
	  partition p_nulls values less than (0) 来创建第一个分区，如果插入的数据都是有效的，那么
	  第一个分区就是空的，即使需要检测第一个分区，代价也会非常小。
	  
	  在mysql 5.5就不需要这个技巧了，因为可以直接使用列本身而不是基于列的函数进行分区。
	  partition by range columns(order_date).
	  
	 2) 分区列和索引列不匹配
	    如果定义的索引咧和分区列不匹配，会导致查询无法进行分区过滤。假如在b列上建立索引	，在a列上进行分区。
		因为每个分区都有其独立的索引，所以扫描列a上的索引就需要扫描每一个分区内对应的索引。要避免这种情况，就要避免建立和分区不匹配的索引，除非查询中还同时包含了可以过滤分区的条件。
	  
	 3) 选择分区的成本可能很高
	    对于使用范围来分区的情况来说，查询的成本可能会非常高。这一行属于哪个分区，这些符合查询条件的行分布在那些区
		找到这样的回答的代价可能会非常高。随着分区数的增长，成本会越来越高。
		在按行写入大量数据的时候，每写入一行数据到范围分区的表时，都需要扫描分区定义列表来找到合适的分区。
		
		可以通过限制分区的数量来缓解这类问题，对于大多数系统来说100个分区是没有问题的。
		其他的分区类型，比如键分区和哈希分区，则没有这样的问题。
		
	 4) 打开并锁住所有底层表的成本可能很高
	    当查询访问分区表的时候，mysql需要打开并锁住所有的底层表，这是分区表的另一个开销。这个操作在分区过滤之前发生，所以无法通过分区过滤
		降低此开销，并且该开销也和分区类型无关，会影响所有的查询。这一点对于一些本身操作非常快的查询，比如根据主键查找
		单行，会带来明显的额外开销。
		
		我们可以通过使用批量操作的方式来降低这个操作带来的开销。同时还需要限制分区的个数。
		
	 5) 维护分区的成本可能很高	  
	  
	  
	  
	  
	  
	  
	  
	  

   请尊重知识，请尊重原创 更多资料参考请见  http://www.cezuwang.com/listFilm?page=1&areaId=906&filmTypeId=1