mysql 分表和分区的个人理解

背景：接之前描述的开发情况，在项目里既需要记录好历史基础数据，也要在查询的时候响应速度能快些。在没有多台服务器可以供自己考虑研究Hadoop做集群的情况下，只能继续看看mysql的分区和分表了。

mysql的分表：主要指在纵向上的，将大记录量的数据表分成一张张的小表进行存储，比如300W数据的表，分成4张表后，每张表的数据量级就会不超过100W了。对于横向上的分表，主要是针对表的列字段的。比如一张销售数据基础表，会统计重要的商品信息、店铺信息、支付信息等。如果将其放在一张表中，首先会使得表字段很多，占用大量的空间，其次，会产生很多的重复字段数据(比如，一家店铺有100个商品在销售数据表里，然后这张表放的数据时完整，就会导致这家店铺的信息，被重复存放了多次。所以，在一些情况下是必须建立一个店铺关联表的，用店铺唯一id存入到这张基础表，相应的店铺信息存入到扩展表，展示需要店铺信息的时候再进行关联表查询)。在纵向表上建分表对应的就需要建合并表。因为合并表要求，所有分表的结构一样，合并表和分表结构一样，否则会失效。所以，纵向分表我个人理解可能更适应于像存放基础数据这样的场景，因为基础数据的结构一般不会改动，即使改动也不会频繁。

mysql的分区：主要是通过partition分区，分区的好处在于实际上还是一张表，只是在数据储存的时候，放在硬盘的不同位置(这块的详细理论我不是很清楚)。这样子的话，当你需要修改数据结构的时候就可以很方便了。但是，分区的时候，对于索引的应用会有些麻烦(这个是在博文里看到的，没有测试过，有兴趣的朋友可以自己谷歌分区 索引这两个关键词)。

具体对于mysql的分区和分表在性能上的影响，我手头上没有1000W级的数据表，所以没有做过比较(我自己理解数据量级没达到的话，测试的结果应该也不足以作为结论的)。

回到自己的应用场景后，因为记录历史基础数据，考虑到基础数据的结构不会频繁修改，所以用分表以及合并表的形式来存历史数据基础数据。考虑到要查询的快一些，所以打算对基础数据进行横向切分建立扩展表之外，进行纵向的分区操作(为了分区数据存放的平均，我选用的是基于自增id的hash分区)。

以上是我对于自己遇到的每周10W增量，查询时间限制2年，历史数据保留完整需求的分区和分表理解。之后再写下具体的操作控制。