说说阿里云RDS MySQL的一些缺点
RDS MySQL用了有一小段时间了，来说一说它的缺点（优点是不用我提的，它的文档、客服、技术支持人员都会告诉您）
首先说说它对比原版所做的优化改进，说到这方面的时候，应该会有很多人说，阿里的技术牛，他在这方面肯定做了很多优化，用RDS一定比官方的跑得快，但事实上，如果你真正看过它与官方版本的功能对比，你会发现，RDS所列出来的功能优势，是体现在外部功能扩展上，核心的优化并没有提（也许你会认为它是谦虚），但事实上，我们拿了一些常见的操作，在RDS与官方版本之间做对比，我们并没有发现RDS有这方面的优化，比如我们已知的 UPDATE xx WHERE ID IN(SELECT ID FROM XXX)，这个写法需要强制改成JOIN的方式，不然通常会有性能问题；SELECT A.* FROM a LEFT JOIN B ON A.ID=B.ID，在A/B都的ID都是主键的情况下，LEFT JOIN是可以省掉的，这些在RDS上并没有被优化；而一些BUG，在RDS上仍然存在。我们知道，基于开源的产品去维护一个独立的产品分支，让它按照我们自己的意愿发展，其成本是很高的，最佳的做法是贡献我们对产品的改进，让融进未来官方发布的产品中（具体我不是很懂哈，说错了可以扔鲜花）。所以从产品表现来看，我们可以相信阿里的技术，但我们不能期待在同版本的产品上，它会比官方的产品有多大的优势。
再来说说RDS MySQL自身产品的成熟度，这个方面的表现有点让我怀疑人生。我们遇到了这样一些不得不说的问题。
首先，在配置方面，只能从页面进行配置，难道就不能在数据库中配置之后页面反读一下？当然，这个不是什么大问题，大问题是：我们改了配置之后，可以直接生效的那种还好，有些配置是需要重启生效的，问题就来了，要么我立即重启，要么我放弃配置，就不能保存配置，延迟到指定时间重启？或者配合一些维护操作一起重启？
配置上的第二个糟心的事，在MySQL中，某些配置是不需要重启的，但在RDS MySQL中必须重启，这个我并没有去测试过，但我遇到了开启general_log必须重启的问题，某些时候我们是需要捕获一下短时间内所有数据库上的SQL的，如果是自己搭建的MySQL，不管是网络抓包还是开general_log，都能够轻松搞定，到了RDS MySQL，这个就玩不转了，开下general_log得重启。另外，比这更糟心的是，你千万不要去开启general_log，如果你是基础版的RDS MySQL，也不要去开启slow_log，因为你没有权限去删除这两个表的数据，所以如果你一旦开启了，那么数据就一直放那里了，官方技术支持明确给出的答复是现在只能这样了。
再说说监控，我遇到了CPU很高的问题，当我解决完问题回头再看监控的时候，我发现怎么CPU还是那么高，于是我刷新了，结果还是没动，然后，然后我发现那个图是设置了开始时间和结束时间的，怎么刷新这个时间阳不会动，于是我只能看一次改一次了（好吧，最终我还是用API把数据扔到自己的数据库中，然后Grafana）。慢查询日志亦是如此，统计太死板了，还是API弄回来自己折腾吧。
继续说说高可用区的问题，我们用的是RDS高可用版，可用区当然是用两个，不然RDS的两个副本可能会在同一硬件上，那硬件出问题乐子就大了，然后我们检查发现居然有个RDS是用的同一可用区，到底是买错了还是硬件升级导致的已经无从考证（反正购买的人说是多可用区，中间做过硬件升级），然后我们准备切换为多可用区，本来以为这应该是so easy的事，备库迁移一下就行了吧，应该不至于要停机，结果，结果单可用区变多可用区需要迁移的是主库，它的做法是在新可用区搭建一个备库，完成之后在主库和这个新备库之间做一个切换，然后干掉原来的备库。所以迁移会有30秒的闪断（没懂为十么）
备份上也可以吐槽一下，它是支持逻辑备份的，但我在自动备份设置中没找到，只在手工备份中有。物理备份是快，但这个备份要拿到自己的机器上还原需要一些技巧，所以在数据量不大的情况下，我们还是倾向于直接逻辑备份的。
最后说的这个不算缺点，RDS高可用会收两个结点的钱，毕竟是双结点嘛，但你永远只能用一个结点，另一个结点是不能开放给你做只读的，如果你要读写分离，那么需要再购买一个。你也不能在RDS上玩一些之前在主从上常玩的技巧操作，比如我们改大表，可以先改从库，然后在切换主从后改新从库，这些统统没戏。