A. 如何实现数据迁移
数据迁移(又称分级存储管理，hierarchical storage management，hsm)是一种将离线存储与在线存储融合的技术。它将高速、高容量的非在线存储设备作为磁盘设备的下一级设备，然后将磁盘中常用的 数据按指定的策略自动迁移到磁带库（简称带库）等二级大容量存储设备上。当需要使用这些数据时，分级存储系统会自动将这些数据从下一级存储设备调回到上一 级磁盘上。对于用户来说，上述数据迁移操作完全是透明的，只是在访问磁盘的速度上略有怠慢，而在逻辑磁盘的容量上明显感觉大大提高了。
数据迁移是将很少使用或不用的文件移到辅助存储系统(如磁带或光盘)的存档过程。这些文件通常是需在未来任何时间可进行方便访问的图像文档或历史信息。迁移工作与备份策略相结合,并且仍要求定期备份。还包括电脑数据迁移，迁移旧电脑（旧系统）中的数据、应用程序、个性化设置等到新电脑（新系统），在系统升级后很有必要。
B. 数据库架构选型与落地，看这篇就够了
随着时间和业务的发展，数据库中的数据量增长是不可控的，库和表中的数据会越来越大，随之带来的是更高的 磁盘 、 IO 、 系统开销 ，甚至 性能 上的瓶颈，而单台服务器的 资源终究是有限 的。
因此在面对业务扩张过程中，应用程序对数据库系统的 健壮性 ， 安全性 ， 扩展性 提出了更高的要求。
以下，我从数据库架构、选型与落地来让大家入门。
数据库会面临什么样的挑战呢？
业务刚开始我们只用单机数据库就够了，但随着业务增长，数据规模和用户规模上升，这个时候数据库会面临IO瓶颈、存储瓶颈、可用性、安全性问题。
为了解决上述的各种问题，数据库衍生了出不同的架构来解决不同的场景需求。
将数据库的写操作和读操作分离，主库接收写请求，使用多个从库副本负责读请求，从库和主库同步更新数据保持数据一致性，从库可以水平扩展，用于面对读请求的增加。
这个模式也就是常说的读写分离，针对的是小规模数据，而且存在大量读操作的场景。
因为主从的数据是相同的，一旦主库宕机的时候，从库可以 切换为主库提供写入 ，所以这个架构也可以提高数据库系统的 安全性 和 可用性 ；
优点：
缺点：
在数据库遇到 IO瓶颈 过程中，如果IO集中在某一块的业务中，这个时候可以考虑的就是垂直分库，将热点业务拆分出去，避免由 热点业务 的 密集IO请求 影响了其他正常业务，所以垂直分库也叫 业务分库 。
优点：
缺点：
在数据库遇到存储瓶颈的时候，由于数据量过大造成索引性能下降。
这个时候可以考虑将数据做水平拆分，针对数据量巨大的单张表，按照某种规则，切分到多张表里面去。
但是这些表还是在同一个库中，所以库级别的数据库操作还是有IO瓶颈（单个服务器的IO有上限）。
所以水平分表主要还是针对 数据量较大 ，整体业务 请求量较低 的场景。
优点：
缺点：
四、分库分表
在数据库遇到存储瓶颈和IO瓶颈的时候，数据量过大造成索引性能下降，加上同一时间需要处理大规模的业务请求，这个时候单库的IO上限会限制处理效率。
所以需要将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同。
分库分表能够有效地缓解单机和单库的 性能瓶颈和压力 ，突破IO、连接数、硬件资源等的瓶颈。
优点：
缺点：
注：分库还是分表核心关键是有没有IO瓶颈 。
分片方式都有什么呢？
RANGE（范围分片）
将业务表中的某个 关键字段排序 后，按照顺序从0到10000一个表，10001到20000一个表。最常见的就是 按照时间切分 （月表、年表）。
比如将6个月前，甚至一年前的数据切出去放到另外的一张表，因为随着时间流逝，这些表的数据被查询的概率变小，银行的交易记录多数是采用这种方式。
优点：
缺点：
HASH（哈希分片）
将订单作为主表，然后将其相关的业务表作为附表，取用户id然后 hash取模 ，分配到不同的数据表或者数据库上。
优点：
缺点：
讲到这里，我们已经知道数据库有哪些架构，解决的是哪些问题，因此， 我们在日常设计中需要根据数据的特点，数据的倾向性，数据的安全性等来选择不同的架构 。
那么，我们应该如何选择数据库架构呢？
虽然把上面的架构全部组合在一起可以形成一个强大的高可用，高负载的数据库系统，但是架构选择合适才是最重要的。
混合架构虽然能够解决所有的场景的问题，但是也会面临更多的挑战，你以为的完美架构，背后其实有着更多的坑。
1、对事务支持
分库分表后（无论是垂直还是水平拆分），就成了分布式事务了，如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价（XA事务）；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担（TCC、SAGA）。
2、多库结果集合并 （group by，order by）
由于数据分布于不同的数据库中，无法直接对其做分页、分组、排序等操作，一般应对这种多库结果集合并的查询业务都需要采用数据清洗、同步等其他手段处理（TIDB、KUDU等）。
3、数据延迟
主从架构下的多副本机制和水平分库后的聚合库都会存在主数据和副本数据之间的延迟问题。
4、跨库join
分库分表后表之间的关联操作将受到限制，我们无法join位于不同分库的表（垂直），也无法join分表粒度不同的表（水平）， 结果原本一次查询就能够完成的业务，可能需要多次查询才能完成。
5、分片扩容
水平分片之后，一旦需要做扩容时。需要将对应的数据做一次迁移，成本代价都极高的。
6、ID生成
分库分表后由于数据库独立，原有的基于数据库自增ID将无法再使用，这个时候需要采用其他外部的ID生成方案。
一、应用层依赖类（JDBC）
这类分库分表中间件的特点就是和应用强耦合，需要应用显示依赖相应的jar包（以Java为例），比如知名的TDDL、当当开源的 sharding-jdbc 、蘑菇街的TSharding等。
此类中间件的基本思路就是重新实现JDBC的API，通过重新实现 DataSource 、 PrepareStatement 等操作数据库的接口，让应用层在 基本 不改变业务代码的情况下透明地实现分库分表的能力。
中间件给上层应用提供熟悉的JDBC API，内部通过 sql解析 、 sql重写 、 sql路由 等一系列的准备工作获取真正可执行的sql，然后底层再按照传统的方法（比如数据库连接池）获取物理连接来执行sql，最后把数据 结果合并 处理成ResultSet返回给应用层。
优点
缺点
二、中间层代理类（Proxy）
这类分库分表中间件的核心原理是在应用和数据库的连接之间搭起一个 代理层 ，上层应用以 标准的MySQL协议 来连接代理层，然后代理层负责 转发请求 到底层的MySQL物理实例，这种方式对应用只有一个要求，就是只要用MySQL协议来通信即可。
所以用MySQL Navicat这种纯的客户端都可以直接连接你的分布式数据库，自然也天然 支持所有的编程语言 。
在技术实现上除了和应用层依赖类中间件基本相似外，代理类的分库分表产品必须实现标准的MySQL协议，某种意义上讲数据库代理层转发的就是MySQL协议请求，就像Nginx转发的是Http协议请求。
比较有代表性的产品有开创性质的Amoeba、阿里开源的Cobar、社区发展比较好的 Mycat （基于Cobar开发）等。
优点
缺点
JDBC方案 ：无中心化架构，兼容市面上大多数关系型数据库，适用于开发高性能的轻量级 OLTP 应用（面向前台）。
Proxy方案 ：提供静态入口以及异构语言的支持，适用于 OLAP 应用（面向后台）以及对分片数据库进行管理和运维的场景。
混合方案 ：在大型复杂系统中存在面向C端用户的前台应用，也有面向企业分析的后台应用，这个时候就可以采用混合模式。
JDBC 采用无中心化架构，适用于 Java 开发的高性能的轻量级 OLTP 应用；Proxy 提供静态入口以及异构语言的支持，适用于 OLAP 应用以及对分片数据库进行管理和运维的场景。
ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由 Sharding-JDBC 、 Sharding-Proxy 和 Sharding-Sidecar （计划中）这3款相互独立的产品组成，他们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。
ShardingSphere提供的核心功能：
Sharding-Proxy
定位为透明化的 数据库代理端 ，提供封装了 数据库二进制协议的服务端版本 ，用于完成对 异构语言的支持 。
目前已提供MySQL版本，它可以使用 任何兼容MySQL协议的访问客户端 (如：MySQL Command Client, MySQL Workbench, Navicat等)操作数据，对DBA更加友好。
向 应用程序完全透明 ，可直接当做MySQL使用。
适用于任何兼容MySQL协议的客户端。
Sharding-JDBC
定位为 轻量级Java框架 ，在Java的JDBC层提供的额外服务。 它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为 增强版的JDBC驱动，完全兼容JDBC和各种ORM框架 。
以电商SaaS系统为例，前台应用采用Sharding-JDBC，根据业务场景的差异主要分为三种方案。
分库（用户）
问题解析：头部企业日活高并发高，单独分库避免干扰其他企业用户，用户数据的增长缓慢可以不分表。
拆分维度：企业ID分库
拆分策略：头部企业单独库、非头部企业一个库
分库分表（订单）
问题解析：订单数据增长速度较快，在分库之余需要分表。
拆分维度：企业ID分库、用户ID分表
拆分策略：头部企业单独库、非头部企业一个库，分库之后用户ID取模拆分表
单库分表（附件）
问题解析：附件数据特点是并发量不大，只需要解决数据增长问题，所以单库IO足以支撑的情况下分表即可。
拆分维度：用户ID分表
拆分策略：用户ID取模分表
问题一：分布式事务
分布式事务过于复杂也是分布式系统最难处理的问题，由于篇幅有限，后续会开篇专讲这一块内容。
问题二：分布式ID
问题三：跨片查询
举个例子，以用户id分片之后，需要根据企业id查询企业所有用户信息。
sharding针对跨片查询也是能够支持的，本质上sharding的跨片查询是采用同时查询多个分片的数据，然后聚合结果返回，这个方式对资源耗费比较大，特别是对数据库连接资源的消耗。
假设分4个数据库，8个表，则sharding会同时发出32个SQL去查询。一下子消耗掉了32个连接；
特别是针对单库分表的情况要注意，假设单库分64个表，则要消耗64个连接。如果我们部署了2个节点，这个时候两个节点同时查询的话，就会遇到数据库连接数上限问题（mysql默认100连接数）
问题四：分片扩容
随着数据增长，每个片区的数据也会达到瓶颈，这个时候需要将原有的分片数量进行增加。由于增加了片区，原先的hash规则也跟着变化，造成了需要将旧数据做迁移。
假设原先1个亿的数据，hash分64个表，现在增长到50亿的数据，需要扩容到128个表，一旦扩容就需要将这50亿的数据做一次迁移，迁移成本是无法想象的。
问题五：一致性哈希
首先，求出每个 服务器的hash值 ，将其配置到一个 0~2^n 的圆环上 （n通常取32）
其次，用同样的方法求出待 存储对象的主键 hash值 ，也将其配置到这个圆环上。
然后，从数据映射到的位置开始顺时针查找，将数据分布到找到的第一个服务器节点上。
一致性hash的优点在于加入和删除节点时只会影响到在哈希环中相邻的节点，而对其他节点没有影响。
所以使用一致性哈希在集群扩容过程中可以减少数据的迁移。
好了，这次分享到这里，我们日常的实践可能只会用到其中一种方案，但它不是数据库架构的全貌，打开技术视野，才能更好地把存储工具利用起来。
老规矩，一键三连，日入两千，点赞在看，年薪百万！
本文作者：Jensen
7年Java老兵，小米主题设计师，手机输入法设计师，ProcessOn特邀讲师。
曾涉猎航空、电信、IoT、垂直电商产品研发，现就职于某知名电商企业。
技术公众号 【架构师修行录】 号主，专注于分享日常架构、技术、职场干货，Java Goals：架构师。
交个朋友，一起成长！
C. mysql数据库读写分离中间层代理插件都有哪些
mysql-proxy是官方提供的mysql中间件产品可以实现负载平衡，读写分离，failover等，但其不支持大数据量的分库分表且性能较差。 其他mysql开源中间件产品有：Atlas，cobar，tddl。你可以查阅一下相关信息和各自的优缺点。
D. 数据库中排序的对比及使用条件详解
假定MySQL服务器和PHP服务器都已经按照最适合的方式来配置，那么系统的可伸缩性(Scalability)和用户感知性能(User-perceived
Performance)是我们追求的主要目标。在实际运行中，MYSQL
中数据往往以
HASH
tables、BTREE
等方式存贮于内存，操作速度很快;同时INDEX
已经进行了一些预排序;很多应用中，MySQL
排序是首选。
PHP与MySQL相比具有如下优势：
1、考虑整个网站的可伸缩性和整体性能，在应用层(PHP)中排序明显会降低数据库的负载，从而提升整个网站的扩展能力。而数据库的排序，实际上成本是非常高的，消耗内存、CPU，如果并发的排序很多，DB
很容易到瓶颈。
2、如果在应用层(PHP)和MYSQL之间还存在数据中间层，合理利用，PHP会有更好的收益。
3、PHP在内存中的数据结构专门针对具体应用来设计，比数据库更为简洁、高效;
4、PHP不用考虑数据灾难恢复问题，可以减少这部分的操作损耗;
5、PHP不存在表的锁定问题;
6、MySQL中排序，请求和结果返回还需要通过网络连接来进行，而PHP中排序之后就可以直接返回了，减少了网络IO。
至于执行速度，差异应该不会很大，除非应用设计有问题，造成大量不必要的网络IO。另外，应用层要注意PHP
的
Cache
设置，如果超出会报告内部错误;此时要根据应用做好评估，或者调整Cache。具体选择，将取决于具体的应用。
列出一些PHP中执行排序更优的情况：
1、数据源不在MySQL
中，存在硬盘、内存或者来自网络的请求等;
2、数据存在
MySQL
中，量不大，而且没有相应的索引，此时把数据取出来用PHP排序更快;
3、数据源来自于多个MySQL
服务器，此时从多个
MySQL
中取出数据，然后在PHP中排序更快;
4、除了MySQL
之外，存在其他数据源，比如硬盘、内存或者来自网络的请求等，此时不适合把这些数据存入MySQL
后再排序;
列出一些必须在MySQL中排序的实例：
1、MySQL中已经存在这个排序的索引;
2、MySQL中数据量较大，而结果集需要其中很小的一个子集;比如
1000000
行数据，取TOP
10;
3、对于一次排序、多次调用的情况，比如统计聚合的情形，可以提供给不同的服务使用，那么在MySQL
中排序是首选的。另外，对于数据深度挖掘，通常做法是在应用层做完排序等复杂操作，把结果存入MySQL即可，便于多次使用。
4、不论数据源来自哪里，当数据量大到一定的规模后，由于占用内存/Cache
的关系，不再适合PHP中排序了;此时把数据复制、导入或者存在MySQL
，并用INDEX
优化，是优于PHP
的。不过，用
Java，甚至
C++
来处理这类操作会更好。
有些类似大数据集聚合或者汇总的数据，在客户端排序得不偿失。当然，也有用类似搜索引擎的思路来解决类似应用的情况。
从网站整体考虑，就必须加入人力和成本的考虑。假如网站规模和负载较小，而人力有限(人数和能力都可能有限)，此时在应用层(PHP)做排序要做不少开发和调试工作，耗费时间，得不偿失;不如在DB
中处理，简单快速。对于大规模的网站，电力、服务器的费用很高，在系统架构上精打细算，可以节约大量的费用，是公司持续发展之必要;此时如果能在应用层(PHP)
进行排序并满足业务需求，尽量在应用层进行。
关于PHP中执行排序与MySQL中执行排序的相关知识就介绍到这里了，希望本次的介绍能够对您有所收获!
E. 负载均衡 后 mysql 怎么连不上
MySQL Proxy就是这么一个中间层代理，简单的说，MySQL Proxy就是一个连接池，负责将前台应用的连接请求转发给后台的数据库，并且通过使用lua脚本，可以实现复杂的连接控制和过滤，从而实现读写分离和负载平衡。
对于应用来说，MySQL Proxy是完全透明的，应用则只需要连接到MySQL Proxy的监听端口即可。当然，这样proxy机器可能成为单点失效，但完全可以使用多个proxy机器做为冗余，在应用服务器的连接池配置中配置到多个proxy的连接参数即可。建议proxy别跟mysql数据库安装在一台服务器中。
F. MySQL的sharding的程序是不是要自己开发的
不一定需要自己开发。Shard层可以位于：
1、DAO层：一般需要自行开发，可以灵活定制
2、ORM层：比如guzz、Hibernate Shard
3、JDBC API层：比较难，有一个商业产品dbShards
4、应用服务器与数据库之间通过代理实现：MySQL Proxy、amoeba.....
一 背景
当数据库中的数据量越来越大时，不论是读还是写，压力都会变得越来越大。采用MySQL
Replication多master多slave方案，在上层做负载均衡，虽然能够一定程度上缓解压力。但是当一张表中的数据变得非常庞大时，压力还是
非常大的。试想，如果一张表中的数据量达到了千万甚至上亿级别的时候，不管是建索引，优化缓存等，都会面临巨大的性能压力。
二 定义
数据sharding，也称作数据切分，或分区。是指通过某种条件，把同一个数据库中的数据分散到多个数据库或多台机器上，以减小单台机器压力。
三 分类
数据分区根据切分规则，可以分为两类：
1、垂直切分
数据的垂直切分，也可以称之为纵向切分。将数据库想象成为由很多个一大块一大块的“数据块”(表)组成，我们垂直的将这些“数据块”切开，然后将他们分散
到多台数据库主机上面。这样的切分方法就是一个垂直(纵向)的数据切分。以表为单位，把不同的表分散到不同的数据库或主机上。规则简单，实施方便，适合业
务之间耦合度低的系统。
Sharding详解" title="MySQL Sharding详解" height="373" width="553">
垂直切分的优点
(1)数据库的拆分简单明了，拆分规则明确;
(2)应用程序模块清晰明确，整合容易;
(3)数据维护方便易行，容易定位;
垂直切分的缺点
(1)部分表关联无法在数据库级别完成，需要在程序中完成;
(2)对于访问极其频繁且数据量超大的表仍然存在性能平静，不一定能满足要求;
(3)事务处理相对更为复杂;
(4) 切分达到一定程度之后，扩展性会遇到限制;
(5)过读切分可能会带来系统过渡复杂而难以维护。
2、水平切分
一般来说，简单的水平切分主要是将某个访问极其平凡的表再按照某个字段的某种规则来分散到多个表之中，每个表中包含一部分数据。以行为单位，将同一个表中的数据按照某种条件拆分到不同的数据库或主机上。相对复杂，适合单表巨大的系统。
Sharding详解" title="MySQL Sharding详解" height="372" width="553">
水平切分的优点
(1)表关联基本能够在数据库端全部完成;
(2)不会存在某些超大型数据量和高负载的表遇到瓶颈的问题;
(3)应用程序端整体架构改动相对较少;
(4)事务处理相对简单;
(5)只要切分规则能够定义好，基本上较难遇到扩展性限制;
水平切分的缺点
(1)切分规则相对更为复杂，很难抽象出一个能够满足整个数据库的切分规则;
(2)后期数据的维护难度有所增加，人为手工定位数据更困难;
(3)应用系统各模块耦合度较高，可能会对后面数据的迁移拆分造成一定的困难。
3、联合切分
实际的应用场景中，除了那些负载并不是太大，业务逻辑也相对较简单的系统可以通过上面两种切分方法之一来解决扩展性问题之外，恐怕其他大部分业务逻辑稍微
复杂一点，系统负载大一些的系统，都无法通过上面任何一种数据的切分方法来实现较好的扩展性，而需要将上述两种切分方法结合使用，不同的场景使用不同的切
分方法。
Sharding详解" title="MySQL Sharding详解" height="480" width="342">
联合切分的优点
(1)可以充分利用垂直切分和水平切分各自的优势而避免各自的缺陷;
(2)让系统扩展性得到最大化提升;
联合切分的缺点
(1)数据库系统架构比较复杂，维护难度更大;
(2)应用程序架构也相对更复杂;
四 实现方案
现在 Sharding 相关的软件实现其实不少，基于数据库层、DAO 层、不同语言下也都不乏案例。限于篇幅，此处只作一下简要的介绍。
1、 Mysql Proxy + HASCALE
一套比较有潜力的方案。其中MySQL Proxy 是用 Lua 脚本实现的，介于客户端与服务器端之间，扮演 Proxy
的角色，提供查询分析、失败接管、查询过滤、调整等功能。目前的 0.6 版本还做不到读、写分离。HSCALE 则是针对 MySQL Proxy 插件，也是用
Lua 实现的，对 Sharding 过程简化了许多。需要指出的是，MySQL Proxy 与 HSCALE
各自会带来一定的开销，但这个开销与集中式数据处理方式单条查询的开销还是要小的。
MySQLProxy是MySQL官方提供的一个数据库代理层产品，和MySQLServer一样，同样是一个基于GPL开源协议的开源产品。可用来监视、分析或者传输他们之间的通讯信息。他的灵活性允许你最大限度的使用它，目前具备的功能主要有连接路由，Query分析，Query过滤和修改，负载均衡，以及基本的HA机制等。
实际上，MySQLProxy本身并不具有上述所有的这些功能，而是提供了实现上述功能的基础。要实现这些功能，还需要通过我们自行编写LUA脚本来实现。
MySQLProxy实际上是在客户端请求与MySQLServer之间建立了一个连接池。所有客户端请求都是发向MySQLProxy，然后经由MySQLProxy进行相应的分析，判断出是读操作还是写操作，分发至对应的MySQLServer上。对于多节点Slave集群，也可以起做到负载均衡的效果。以下是MySQLProxy的基本架构图：
Sharding详解" title="MySQL Sharding详解" height="480" width="420">
通过上面的架构简图，我们可以很清晰的看出MySQLProxy在实际应用中所处的位置，以及能做的基本事情。关于MySQLProxy更为详细的实施细则在MySQL官方文档中有非常详细的介绍和示例，感兴趣的读者朋友可以直接从MySQL官方网站免费下载或者在线阅读，我这里就不累述浪费纸张了。
http://forge.mysql.com/wiki/MySQL_Proxy
2、 Hibernate Shards
这是 Google 技术团队贡献的项目(http://www.hibernate.org/414.html)，该项目是在对Google 财务系统数据
Sharding 过程中诞生的。因为是在框架层实现的，所以有其独特的特性：标准的 Hibernate 编程模型，会用 Hibernate
就能搞定，技术成本较低;相对弹性的 Sharding 策略以及支持虚拟 Shard 等。
3、 Spock Proxy
这也是在实际需求中产生的一个开源项目，基于Mysql Proxy扩展。Spock(http://www.spock.com/)是一个人员查找的 Web
2.0 网站。通过对自己的单一 DB 进行有效 Sharding化 而产生了Spock
Proxy(http://spockproxy.sourceforge.net/ ) 项目，Spock Proxy 算得上 MySQL Proxy
的一个分支，提供基于范围的 Sharding 机制。Spock 是基于 Rails 的，所以Spock Proxy 也是基于 Rails 构建，关注 ROR
的朋友不应错过这个项目。
http://spockproxy.sourceforge.net/
4、 Amoeba for MySQL
Amoeba是一个基于Java开发的，专注于解决分布式数据库数据源整合Proxy程序的开源框架，基于GPL3开源协议。目前，Amoeba已经具有Query路由，Query过滤，读写分离，负载均衡以及HA机制等相关内容。
Amoeba 主要解决的以下几个问题：
(1)数据切分后复杂数据源整合;
(2)提供数据切分规则并降低数据切分规则给数据库带来的影响;
(3)降低数据库与客户端的连接数;
(4)读写分离路由。
我们可以看出，Amoeba所做的事情，正好就是我们通过数据切分来提升数据库的扩展性所需要的。
Amoeba并不是一个代理层的Proxy程序，而是一个开发数据库代理层Proxy程序的开发框架，目前基于Amoeba所开发的Proxy程序有AmoebaForMySQL和AmoebaForAladin两个。
AmoebaForMySQL主要是专门针对MySQL数据库的解决方案，前端应用程序请求的协议以及后端连接的数据源数据库都必须是MySQL。对于客户端的任何应用程序来说，AmoebaForMySQL和一个MySQL数据库没有什么区别，任何使用MySQL协议的客户端请求，都可以被AmoebaForMySQL解析并进行相应的处理。下如可以告诉我们AmoebaForMySQL的架构信息(出自Amoeba开发者博客)：
Sharding详解" title="MySQL Sharding详解" height="480" width="384">
AmoebaForAladin则是一个适用更为广泛，功能更为强大的Proxy程序。他可以同时连接不同数据库的数据源为前端应用程序提供服务，但是仅仅接受符合MySQL协议的客户端应用程序请求。也就是说，只要前端应用程序通过MySQL协议连接上来之后，AmoebaForAladin会自动分析Query语句，根据Query语句中所请求的数据来自动识别出该所Query的数据源是在什么类型数据库的哪一个物理主机上面。下图展示了AmoebaForAladin的架构细节(出自Amoeba开发者博客)：
Sharding详解" title="MySQL Sharding详解" height="480" width="384">
咋一看，两者好像完全一样嘛。细看之后，才会发现两者主要的区别仅在于通过MySQLProtocalAdapter处理之后，根据分析结果判断出数据源数据库，然后选择特定的JDBC驱动和相应协议连接后端数据库。
其实通过上面两个架构图大家可能也已经发现了Amoeba的特点了，他仅仅只是一个开发框架，我们除了选择他已经提供的ForMySQL和ForAladin这两款产品之外，还可以基于自身的需求进行相应的二次开发，得到更适应我们自己应用特点的Proxy程序。
当对于使用MySQL数据库来说，不论是AmoebaForMySQL还是AmoebaForAladin都可以很好的使用。当然，考虑到任何一个系统越是复杂，其性能肯定就会有一定的损失，维护成本自然也会相对更高一些。所以，对于仅仅需要使用MySQL数据库的时候，我还是建议使用AmoebaForMySQL。
AmoebaForMySQL的使用非常简单，所有的配置文件都是标准的XML文件，总共有四个配置文件。分别为：
(1)amoeba.xml：主配置文件，配置所有数据源以及Amoeba自身的参数设置;
(2)rule.xml：配置所有Query路由规则的信息;
(3)functionMap.xml：配置用于解析Query中的函数所对应的Java实现类;
(4)rullFunctionMap.xml：配置路由规则中需要使用到的特定函数的实现类;
如果您的规则不是太复杂，基本上仅需要使用到上面四个配置文件中的前面两个就可完成所有工作。Proxy程序常用的功能如读写分离，负载均衡等配置都在amoeba.xml中进行。此外，Amoeba已经支持了实现数据的垂直切分和水平切分的自动路由，路由规则可以在rule.xml进行设置。
目前Amoeba少有欠缺的主要就是其在线管理功能以及对事务的支持了，曾经在与相关开发者的沟通过程中提出过相关的建议，希望能够提供一个可以进行在线维护管理的命令行管理工具，方便在线维护使用，得到的反馈是管理专门的管理模块已经纳入开发日程了。另外在事务支持方面暂时还是Amoeba无法做到的，即使客户端应用在提交给Amoeba的请求是包含事务信息的，Amoeba也会忽略事务相关信息。当然，在经过不断完善之后，我相信事务支持肯定是Amoeba重点考虑增加的feature。
关于Amoeba更为详细的使用方法读者朋友可以通过Amoeba开发者博客(http://amoeba.sf.net)上面提供的使用手册获取，这里就不再细述了。
案例(http://pengranxiang.iteye.com/blog/1145342)
操作文档(http://docs.hexnova.com/amoeba/chap-getting-started.html)
5、 HiveDB
和前面的MySQLProxy以及Amoeba一样，HiveDB同样是一个基于Java针对MySQL数据库的提供数据切分及整合的开源框架，只是目前的HiveDB仅仅支持数据的水平切分。主要解决大数据量下数据库的扩展性及数据的高性能访问问题，同时支持数据的冗余及基本的HA机制。
HiveDB的实现机制与MySQLProxy和Amoeba有一定的差异，他并不是借助MySQL的Replication功能来实现数据的冗余，而是自行实现了数据冗余机制，而其底层主要是基于HibernateShards来实现的数据切分工作。
在HiveDB中，通过用户自定义的各种Partitionkeys(其实就是制定数据切分规则)，将数据分散到多个MySQLServer中。在访问的时候，在运行Query请求的时候，会自动分析过滤条件，并行从多个MySQLServer中读取数据，并合并结果集返回给客户端应用程序。
单纯从功能方面来讲，HiveDB可能并不如MySQLProxy和Amoeba那样强大，但是其数据切分的思路与前面二者并无本质差异。此外，HiveDB并不仅仅只是一个开源爱好者所共享的内容，而是存在商业公司支持的开源项目。
下面是HiveDB官方网站上面一章图片，描述了HiveDB如何来组织数据的基本信息，虽然不能详细的表现出太多架构方面的信息，但是也基本可以展示出其在数据切分方面独特的一面了。
Sharding详解" title="MySQL Sharding详解" height="471" width="553">
http://www.hivedb.org/
6、 DataFabric
application-level sharding
master/slave replication
https://github.com/bpot/data_fabric
7、PL/Proxy
前面几个都是针对MySQL 的 Sharding 方案，PL/Proxy 则是针对 PostgreSQL 的，设计思想类似 Teradata 的
Hash 机制，数据存储对客户端是透明的，客户请求发送到 PL/Proxy 后，由这里分布式存储过程调用，统一分发。 PL/Proxy
的设计初衷就是在这一层充当”数据总线”的职责，所以，当数据吞吐量支撑不住的时候，只需要增加更多的 PL/Proxy 服务器即可。大名鼎鼎的 Skype 用的就是
PL/Proxy 的解决方案。
8、Pyshards
这是个基于Python的解决方案。该工具的设计目标还有个 Re-balancing 在里面，这倒是个比较激进的想法。目前只支持 MySQL
数据库。
http://code.google.com/p/pyshards/wiki/Pyshards
9、其他实现数据切分及整合的解决方案
除了上面介绍的几个数据切分及整合的整体解决方案之外，还存在很多其他同样提供了数据切分与整合的解决方案。如基于MySQLProxy的基础上做了进一步扩展的HSCALE，通过Rails构建的SpockProxy，以及基于Pathon的Pyshards等等。
不管大家选择使用哪一种解决方案，总体设计思路基本上都不应该会有任何变化，那就是通过数据的垂直和水平切分，增强数据库的整体服务能力，让应用系统的整体扩展能力尽可能的提升，扩展方式尽可能的便捷。
只要我们通过中间层Proxy应用程序较好的解决了数据切分和数据源整合问题，那么数据库的线性扩展能力将很容易做到像我们的应用程序一样方便，只需要通过添加廉价的PCServer服务器，即可线性增加数据库集群的整体服务能力，让数据库不再轻易成为应用系统的性能瓶颈。
五 注意事项
下面我们所说的分区，主要是指水平分区。
1、在实施分区前，我们可以查看所安装版本的mysql是否支持分区：
mysql> show variables like "%partition%";
如果支持则会显示：
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| have_partitioning | YES |
+-------------------+-------+
2、分区适用于一个表的所有数据和索引，不能只对数据分区而不对索引分区，反之亦然，同时也不能只对表的一部分进行分区。
3、分区类型
(1)RANGE 分区：基于属于一个给定连续区间的列值，把多行分配给分区。
(2)LIST 分区：类似于按RANGE分区，区别在于LIST分区是基于列值匹配一个离散值集合中的某个值来进行选择。
(3)HASH分区：基于用户定义的表达式的返回值来进行选择的分区，该表达式使用将要插入到表中的这些行的列值进行计算(新浪微博采用的方案)。
(4)KEY 分区：类似于按HASH分区，区别在于KEY分区只支持计算一列或多列，且MySQL
服务器提供其自身的哈希函数。必须有一列或多列包含整数值。
无论使用何种类型的分区，分区总是在创建时就自动的顺序编号，且从0开始记录。当有一新行插入到一个分区表中时，就是使用这些分区编号来识别正确的分区。
4、MySQL提供了许多修改分区表的方式。添加、删除、重新定义、合并或拆分已经存在的分区是可能的。所有这些操作都可以通过使用ALTER TABLE
命令的分区扩展来实现。
5、可以对已经存在的表进行分区，直接使用alter table命令即可。
G. mysql读写分离，应用层分离好还是中间层好
应用层分离：控制上的灵活度更高，实现也简单，随时可以调整策略。但带来的问题就是增加应用层的复杂性以及额外的开发工作，均衡设置、安全防护、分流什么的，不太好加强。适合中小型项目吧，毕竟到后期的扩容方面有点麻烦。
中间层分离：专业的事还是专业的proxy来负责，应用层专心做应用层的事，中间层按规则做读写的分离。扩容均衡起来得心应手，连接池、健康切换，这样都是应用层无法实现的。适合大型超大型项目