MySQL水平SHARDING的两种方法及不足

                          MySQL水平SHARDING的两种方法及不足

     在对mysql数据库进行SHARDING的设计中，基中非常重要的就是选择SHARD KEY和SHARD KEY如何去分布。
选择SHARD KEY的一个基本原则就是能使数据根据业务类型尽量分散在多个SHARDING服务器中.

   第一种方法是选定某个栏位作为SHARD KEY,根据SHARD KEY的特点，可以选择基于hash,range和list进行SHARDING.
比如现在有3个SHARDING节点,根据SHARD KEY的值，分别hash在这三个SHARDING节点中.range表示对于
某个SHARD KEY范围内的值会存放到一个SHARDING节点上.以上几种shared分布的式,相信对于了解分区的
朋友来说一定十分的熟悉.例如有个订单表,表结构如下:

create table order_item
(id integer,
 uid integer,
 amount integer)

alter table order_item add primary key(id);
 
  应用程序生成一个id号，然后再根据id做一个hash操作，比如id为12302，通过hash函数，结果为1,数据在1节点中.
 
  这种SHARD KEY的分布方式有一个很不好的地方就是当需要增加或是减少shared节点的情况很不方
便，需要对以前的所有数据进行重新分布.大数据量的情况下这个过程将会变得非常的耗时.

  另一种方法通过通过建立一个字典表，比如建立一个服务器列表，然后应用程序通过随机函数从表中随机选择
SHARDING节点进行处理,比如

shard id      ip

1            172.28.10.11
2            172.28.10.12
3            172.28.10.13

由应用程序随机产生1-3的随机数，再决定使用哪个服务器进行处理.这种方式的好处是增加SHARDING节点和删除
SHARDING节点都非常的方便.不足的地方是这种方式没有SHARD KEY，数据完全是随机的处理.但是可以通过在redis或是
memcached进行一些优化，比如跟踪原来打算做SHARD KEY的栏位值是分别存放在哪些节点中。

  在之前的例子中，通过在redis或是memcached跟踪id和对应的存放服务器，比如id为12302是存放在2服务器中。当应用程序需要
查询某个id的记录时，先从缓存中查出来该id对应的服务器是第几号就可以了，而不再通过SHARD KEY的规则自己算出哪个SHAREDING
节点,然后再去访问对应的服务器.