MyCat究竟做了什么事情？（总结:路由规划,数据拼接）

作为一个中间层，本职工作应该是接收客户端的SQL请求，然后通过语法分析，根据读写原则，然后确定一个集群中一个读写节点即可，然后就等着结果集的返回，对于结果集本身，中间层并不需要去关心，他只需要将结果集（或者异常）原原本本发回给客户端即可。而MyCat做的事情，远比这个多，在语法分析之后，再做语义分析，拿到对应数据库表结构，同时判断这个表的分发路由规则，再找到语句中的数据及涉及到的列，再决定路由到哪个分片中，如果在分发时路由规则配置错误，或者程序计算错误，会导致整个语句的结果出现不可预知的问题。请问这前半部分，是一个中间层应该做的事情么？竟然还要关心语句中涉及到的表结构，主键，数据等信息，这其实都是数据库要做的事情啊，实则是越俎代庖，再请问，所做的这些事情，能比一个专业数据库做得更好么？咱再看后半部分，等收到结果集之后，MyCat为了处理一些结果集的聚合计算，需要把各个节点本来已经封装好的结果集（二进制MySQL协议流数据），解析出来，然后通过需要计算出来（这个计算有可能非常慢，并且不是所有的都可以搞定），计算完成之后，再打包成MySQL协议流数据，传给客户端，请问这样的中间层，做了这么多事情，性能如何保证？而本身这些聚合计算Order By、Group By的处理，本身是数据库的事情，实则还是越俎代庖。

分片多了的情况下，性能是如何保证损失最小的？(总结:建议数据集中在一个分片,不要跨分片)

这个问题，我并不知道MyCat有没有做过优化，比如10个分片，如果一个语句的执行会涉及到这十个分片，那在每个分片上重写语句之后，就要分别在这十个分片上执行对应的语句了，执行时是串行，还是并行？串行的话，性能必然会下降10倍以上，所以做得好点的话，就是并行了，但并行的实现方法是，在MyCat这个连接上面，创建10个线程，去处理这十个节点的执行情况，那这样的连接多了，MyCat产生的对系统的冲击就非常大了，性能还是不行。当然也可以说，这里做了连接池，没错，是可以的，但MyCat是这样做的么？这样做了性能又如何呢？如果有一个超时，整个访问就失败了。

DDL如何进行？(总结:不支持,如果不想影响业务，只能半夜各个实例数据库同时执行,决定因素:根据数量的大小决定DDL执行时间，大概率需要重启mycat)

这个问题也许是每个人都关心的事情了，MyCat把数据都分而不相关的分片MySQL节点了，这样很多在单点上的改表策略都不能用了，而DDL又是一个必须要保证每个节点同时完成的事情，那在分布式上面是如何保证的呢？根据我的调研，好像现在使用MyCat的人，都是通过“同一时刻启动在每一个节点上更新表结构”这样的方法来做的，当然还得选择是半夜，当然我个人觉得也是可行的，因为毕竟已经使用了它，而没有更好的办法来解决这个问题。当然咱再说后果，如果做不到无缝原子修改，那对业务的影响不是一星半点，可能会有很多SQL会报表不存在的问题。如果一个语句和另一个语句修改完成时间相差比较多的话，两个相减的时间就是故障时间了。

MyCat自动故障切换是否靠谱(总结:不靠谱不建议自动切换,和网络有关,以及服务器本身有关,要做的判断非常复杂)
我们现在讨论的是分布式架构方案，而这个问题讲的情况是，某一个MyCat发现了后端数据库连不上了，会自动切换的功能，这就非常明显了，我们要的是分布式，某“一个”MyCat节点认为的问题就真的是他所认为的吗？也就是说，一个节点并不能保证他判断的或者他看到的现象是真实的，那这种情况下就存在误切换的情况，而如果其它中间层节点还不知道这个情况，或者未及时收到切换的消息，就出现了多点写入的问题，挺可怕的。这不是自相矛盾吗？我们要的是分布式，结果又存在“独断”的环节，可靠性又下降了不少。关于分布式监控切换的问题，因为在去哪儿用的mysql-sentinel对Galera Cluster做的监控，我对这点深有感触，所以不得不在这里讲一下。

在MyCat上如何备份以及恢复(备份总结:各个分片数据库自行执行,由于备份时间取决于各数据库中数据的多寡,故不可能做到数据一致性，由于足球3的数据分片规则,各游戏区在某一时间点，可以做到数据一致性，恢复总结:整体恢复只需要时间即可,各游戏分区恢复非常低效,由于各分区混合在一起,需要先抽出分区数据再进行恢复,需要大量时间)

说起备份，做为数据库使用者，应该没有一个不清楚，没有一个人会觉得他不重要吧？当然，重要是重要，但这种事情属于重要不紧急的工作，但没有是不行的，这个连公司内审这一关都过不了，也许我们每一个人都不会希望能用到他。

言归正传，话说这么重要的备份工作，在MyCat上又是什么情况呢？可能了解一些基本原理的人都比较清楚，Xtrabackup、mysqldump等也都是可以用的，但备份完了之后呢，可能心里还是感觉没底，因为这样的工具，只能对一个MySQL节点做备份，如果分10个分片（10个MySQL节点）的话，可以通过备份十次即可完成，但需要注意的是，备份了十次产生了十个备份集，而并不是一个备份集，这十个备份集之间是完完全全没有关系的，此时我可能就提出一个比较极端的问题来：

如果哪天（当然我们都不希望有这样的一天），整个机房挂了，当然假如“幸运”的是，有备份，那在这种情况下，如何恢复一个可用的数据一致及完整的集群快照呢？

这个时候可能会有人很快地说，将十个备份集都恢复了启动了即可。但问题是这十个没有关系，备份时间又不是同一时刻完成的，同一个表的十个分片，最新数据有的是8点的，有的是9点的，或者有的甚至是昨天的。这样恢复出来的表，能用么？基于这样的表产生的查询结果，靠谱么？可想而知。

当然可能也有人会说，我们的数据不需要一致快照，或者更有甚者只需要备份元数据路由表或者配置文件即可，那这样就没问题了，如果MyCat只是定位于用来存储Zabbix监控数据，或者日志数据，可以丢失不要的数据，一文不值的数据，那我觉得没毛病。

或许有人还会说，我们的机房不会挂，或者我们的存储本来就是跨机房的，挂了的话直接切到另外的机房就行了，那此时又有问题了，如果切换的时候，有复制延迟，丢失了部分数据，那整个集群又会出问题，因为只要有一个分片的数据出问题，整个集群就有问题了。或者另一个问题就是，假设你的机房真的不会挂，但我们经常会遇到的需求是，我要取前几天某时刻的数据，那此时还是需要通过备份然后恢复一个快照，这个时候还有何话可说，你告诉我究竟如何做到？

可能还会有人有疑问，他会说我们是逻辑备份啊，这样备份出来的是整个库或者表的一致性快照，这不就解决问题了么？我很同意这位同学的看法，说得对极了，是可以很完美地解决一致性问题，但只要熟悉一点点MySQL的人都知道，类似mysqldump这样的逻辑备份工具，是何其慢？现在都用分布式存储了，那肯定是数据量非常大，这个时候还在使用这样的逻辑备份？你是想干哈？即使备份完成了，那有没有试过逻辑数据的恢复？几个G的数据要恢复多久，你算过没有？想想都头疼。一条不归路。。。

MyCat数据恢复方案（伪）(总结:各分片数据库下挂从数据库服务器,服务器故障整体替换.缺点:解决不了人为误操作,另外服务器成本增加,最后无论从服务器是否提供读服务,mycat配置文件都要修改,重载配置文件,（最坏情况下,可能重启才有效）对其他游戏区会有影响,业务代码需要支持客户端自动重连)

MyCat最终总结(总结:mycat最重要缺点:没有好用的数据维护工具,不支持特定语法,跨分片性能低下)

mycat一种伪分布式方案，基础是不好的，上层就做不好，所以永远是在补各种坑，走得很累，累人累己。现在可以回过头来想一想，为什么一些很强大知名的公司做的中间件产品，并没有做分库分表这些事情，比如ProxySQL、Maxscale、MySQL Router等，为什么呢？难道他们的技术不好？或者是没有这样的需求？我还是觉得，需求是有的，人与人、业务与业务的需求，是一样的，但解决方法可能就不一样了，他们可能早就认为，这是一条错误的道路，所以就不会去选择走，而MyCat这种方案，可能就要回过头来想想未来的路了。

互联网处理大规模在线访问数据的做法

解耦思想充斥着互联网技术栈的方方面面，为什么这样做？我想应该是大家都不想拖泥带水，也不想牵一发而动全身罢了。而在MySQL数据库层面，使用了重量级的中间层之后，你会发现，大一统看起来是很不错，但这样牵一发很可能动全身，这其实并不是好事情。

MySQL这种数据库是在互联网领域兴起并被大规模使用的，在比如账务、订单、计费等等关键业务上使用的也不在少数。在大型互联网公司，MySQL的使用一定是分库分表的，通过各种垂直切分和水平切分，把一个数据库变成一堆数据库，也就是所说的数据库集群。但是很少看到在使用的MySQL的时候会在上面架设一层重量级的所谓分布式的中间层，这样导致的就是紧耦合了，与互联网的高效联运相违背，互联网的数据库集群都应该是物理上离散的，每一个实例可以自由的控制和迁移，也就是所谓的解耦。

解耦的好处可以让你自由处理每一个独立的实例或者集群，方便根据实际情况应对业务带来的变数，该升级的升级，该缩容的缩容，为每一个业务或者每一个业务的数据库定义不同的维护等级，灵活掌握，随机而变。

解耦的好处可以提升数据库的绝对性能，数据从业务到磁盘，或者从磁盘到业务，经历的路径越短，其效率也就越高。很多使用MySQL的做法就是用一个简单的中间层分发SQL，这样的中间层功能清晰、结构简单、灵活高效，一般不会损失太多性能，这就像MySQL出品的MySQL Router，MariaDB出品的Maxscale，Percona的ProxySQL，还有国内的正火的极数云舟的Arkproxy，他们的行为，都为选择使用中间层去实现数据架构指明了一个方向。

解耦的好处可以让你的数据库只干数据库最擅长的事情，它能保证你的数据安全存储，它能保证你的数据高效存取，它能保证你数据并发处理，它能保证你的数据灵活接入，这还不够吗？

综上所述，我们再次确信一个真理，MySQL因简单而高效，因高效而流行，不要舍本逐末，听信忽悠，误入歧途。