前言：

　　MySQL 5.1+ 版本就开始支持分区功能了。

　　分区本质上就是在物理文件层面划分了多个物理子表来支撑，或者说是一组底层表的句柄对象的封装。

　　对于分区表的请求，都是通过句柄对象转化成对存储引擎的接口调用。

　　从底层的文件系统就可以看出来，使用了 # 分割的命名表文件，就是分区表；

　　ls /home/mysql/data/mysql/　　# 可以查看到

　　什么场景使用分区才能起到非常大的作用：

　　1、表非常大以至于无法全部都放在内存中；（被挤出内存，MySQL 的缓存不起作用了）

　　2、分区表的数据容易维护的。

　　3、分区表的数据可以分布在不同物理设备上的；

　　4、如果需要，可以备份和恢复独立的分区的；

一、分区表原理

　　SELECT 查询：

　　　　当查询一个分区表的时候，分区层先打开并锁住所有的底层表，

　　　　优化器先判断是否可以过滤部分分区，然后再调用对应的存储引擎接口访问各个分区的数据。

　　　　break;

　　INSERT 操作：
　　DELTE 操作：

　　　　当写入一条记录时，分区层先打开并锁住所有底层表，然后确定哪个分区接收这条记录，再写入。

　　　　break;

　　UPDATE 操作：

　　　　当更新一条记录时，分区层先锁底层表，然后寻找哪个分区，然后取数据更新。

　　　　更新完成后再看数据应该放在哪个分区，如果跨分区则删除老分区、写入新分区；

　　// 所谓的锁住底层表，也是针对不同存储引擎而来的；

二、如何选择性分区

　　分区技巧：

　　1、可以根据键值进行分区，来减少 InnoDB 的互斥量竞争；

　　2、使用数学模函数来进行分区，然后将数据轮询放入不同的分区。

　　　　如，针对日期做模 7 的运算，或者简单使用周几的函数，进行分区；

　　3、假设表有一个自增主键列 ID，希望根据时间将最近的热点数据集中存放，

　　　　这种情况可以采用这样的分区表达式来实现：HASH(ID DIV 100000)，这将

　　　　为 100 万数据建立一个分区。

　　在数据量超大的时候，B-Tree 索引就无法起作用了，除非是索引覆盖查询，否则数据库服务器需要根据索引扫描的结果回表，

　　查询所有符合条件的记录，如果数据量巨大，这将产生大量随机 I/O，数据库响应时间将大到不可接受的程度，另外索引维护成本也非常高； 　　

　　分区策略：

　　1、全量扫描数据，不要任何索引。

　　　　可以使用简单的分区方式存放表，不要任何索引，根据分区的规则大致定位需要的数据位置。

　　　　只要能够使用 WHERE 条件，将需要的数据限制在少数分区中，则效率很高的。

　　　　当然，也需要做一些简单的运算保证查询的响应时间能够满意需求。

　　　　此策略适用于以正常的方式访问大量数据的时候。

　　2、索引数据，并分离热点。

　　　　如果数据有明显的 “热点”，而且除了这部分数据，其他数据很少被访问，那么可以独立出一个分区，

　　　　让这个分区的数据能够有机会缓存在内存中。

　　分区的坑：

　　1、NULL 值会使分区过滤无效；

　　2、分区列和索引不匹配；

　　　　如果定义的索引列和分区列不匹配，会导致查询无法进行分区的过滤。

　　3、打开并锁住所有底层表的成本可能很高；

　　4、维护分区的成本可能会很高；