Mycat中间件技术研究

Mycat是一个开源的分布式数据库系统，其并没有存储引擎，但是Mycat实现了mysql协议，前段用户可以把它当做一个proxy。其核心功能是分库分表，即将一个
大表分库分表为N个小表，存储在后端的Mysql存储引擎里面。最新版本的Mycat不仅支持MS SqlServer， Oracle，DB2等关系型数据库，而且还支持MongoDB
这种NoSQL。

Mycat的原理是先拦截用户的SQL语句做分析：分片分析，路由分析，读写分离分析，缓存分析，再将该SQL语句发送到指定规则的数据库，最终将存储引擎返回的
结果返回给用户。

Sharding-JDBC 与 Mycat 有一定的相似性，区别点在于对于 SQL 语句的自解析上，是否可以这么理解？

      从设计理念上看确实有一定的相似性，主要流程都是SQL解析--> SQL改写-->SQL路由-->SQL
      执行-->结果归并，但架构设计时不同的，Mycat是基于Proxy，它复写了Mysql协议，将Mycat
      Server伪装成一个Mysql Server数据库，而Sharding-JDBC是基于JDBC接口的扩展，是以
      Jar包的形式提供轻量级服务的。

      SQL解析这块，现在的Sharding-JDBC和Mycat也比较相似，都是使用Druid作为SQL解析的基础
      类库，但Sharding-JDBC正在重写SQL解析这块，是去掉Druid的完全自研版本，不可否认，
      Druid是一个优秀的连接池，而且SQL解析这块做的也很强，但它毕竟不是一个专门为了Sharding
      而做的SQL解析器，它的大致解析流程是 Lexer -> Parser -> AST -> Visitor，使用者需要
      实现它的Visitor接口，将自己的业务逻辑在Visitor中实现.

Sharding-JDBC 从 1.3.0 开始支持读写分离

分库分表使用 like 查询，是否能查询出来？性能如何？会去查询所有的库和表吗？
      1)分库分表使用 like 查询是有限制的。目前 Shariding-JDBC 不支持 like 语句中包含分片
        键，但不包含分片键的 like 语句可以正确执行。
      2)至于 like 性能问题，是与数据库相关的，Shariding-JDBC 仅仅是解析 SQL 以及路由至正
        确的数据源而已。
      3)是否会查询所有的库和表是根据分片键决定的，如果 SQL 中不包括分片键，就会查询所有库和
        表，这个和是否有 like 没有关系。

有一个问题一直很疑惑，目前分库分表的中间件有两种**，分别是：

     1)类似 Sharding-JDBC 及 TDDL 的增强版 JDBC 驱动**
     2)类似 Mycat 增加中间层，然后在中间层进行分库分表**
     我想问的是，这两种**都有什么优势和劣势呢，大公司的主流选型又是哪种？

     两种方式各有优缺点：
         JDBC驱动版的优点：
             1）轻量，范围更加容易界定，只是JDBC增强，不包括HA,事务以及数据库元数据管理
             2）开发的工作量较小，无需关注NIO，各个数据库协议等。
             3）运维无需改动，无需关注中间件本身的HA
             5）性能高，JDBC直连数据库，无需二次转发
             6）可支持各种基于JDBC协议的数据库，如Mysql, Oracle, SqlServer
         
         Proxy的优点：
             1）可以负责更多的内容，将数据迁移，分布式事务等纳入Proxy的防臭
             2）更有效的管理数据库的连接
             3）整合大数据思路，将OLTP和OLAP分离处理。

      因此两种方式互相可以互补，建议使用 Java 的团队，且仅 OLTP 的互联网前端操作。有可能会
      使用多种数据库的情况，可以选择 JDBC 层的中间件；如果需要 OLAP 和 OLTP 混合，加以重
      量级的操作，如数据迁移，分布式事务等，可以考虑 Proxy 层的中间件